Re: [whatwg] <time>

Hi Leif,

On Mar 10, 2009, at 11:46 PM, Leif Halvard Silli wrote:

> Charles McCathieNevile 2009-03-11 01.48:
>> On Tue, 10 Mar 2009 18:03:37 +0100, David Singer:
>
>>> I'd rather have the historical pages say "In the 4th year of
>>> the first Indiction cycle of the second reign of the Emperor
>>> Justinian called the golden-nosed, in the 3rd day following
>>> the nones of August, at the hour of dawn in the city of  
>>> Chrysopolis" (and then they give the Gregorian translation, e.g.  
>>> 6am on the 12th of August 707 CE).
>
> You meant: Give the Gregorian date inside the datetime attribute?
> Gregorian date in the text is urelevant in lots of contexts. [1]

The more and more I read this thread the more I feel that trying to  
shoehorn Gregorian dates into this in all circumstances is going to  
needlessly complicate things for everyone involved: users, authors and  
implementors alike. For very limited use cases such Gregorian dates  
might be acceptable but for historical documents, encyclopedias,  
geological, astronomical and all sorts of other disciplinary  
documents, it just is insufficient.

Jim O'Donnel's suggestion would be an improvement or using something  
from RDFa (e.g., including <time datatype='GregorianDate'  
content='1776-07-04t16:10local'>commencement of America's independence  
</time>).

The problems a date/time element might want to address is:

  • expressing a date in one of various calendars (particularly for  
cultural-historical, geological, astronomical, etc. documents  
including encyclopedia articles and other documents).
  • expressing the precision / accuracy / deviation of a date (e.g.,  
<time content='2009-03-19t00:00:00z' deviation='3-days' confidence='1'  
 >next week</time>).
  • Using non-UTC times especially in cultural-historical documents  
where UTC does not exist and it is inaccurate to characterize a time  
as a UTC time (again e.g., including <time datatype='GregorianDate'  
content='1776-07-04t16:10local'>commencement of America's independence  
</time>).
  • identifying the calendar used in the element's contents
  • identifying the calendar used in the element's content or datetime  
attribute
  • providing a mechanism to change the presentation of dates and  
times according to user defaults or stylesheets and in any desired  
calendar, era, and time zone.

>> Indeed. That's one of the ways it can be done. IMHO it meets a
>> huge set of the possible use cases. [...]
>
> The current draft text says that <time> "represents a precise date
> and/or a time in the proleptic Gregorian calendar".
>
> This gives the impression that one cannot use <time> for such
> things as David mentioned. If it is meant that one should be able
> to use <time> for giving the date of the October revolution ...
>
> <p><time datetime="1917-11-7">25 October 1917</time>
> <p><time>25 October 1917</time>
>
> ... then the draft text should be changed to stress that  it is the  
> *datetime* attribute which "represents a precise date
> and/or a time in the proleptic Gregorian calendar".

I think a more forward looking approach would be to acknowledge the  
existence of multiple possible calendars for the datetime or content  
attributes but then say that the Gregorian calendar is the default and  
that implementations are only required to support the Gregorian  
(something similar could be done for the common era with potential  
support for alternate eras especially for the Julian and other non- 
Gregorian calendars, though even the decision of some software  
developers to insert a zero year into the proleptic Gregorian calendar  
can be thought of as an alternate era where the years all coincide  
from AD 1 onwards).

>
>
> The real problem is when e.g. <time>Easter</time> refers to a Julian  
> date before the new calendar was introduced.

Well Easter is largely a holdover from a lunar calendar since its  
always the Sunday after the first full moon after the vernal equinox  
(and the Julian and Gregorian are both non-lunar calendars).

>
> Jim O'Donnell 2009-03-10 19.53:
>> On 10 Mar 2009, at 17:03, David Singer wrote:
>
>>> The trouble is, that opens a large can of worms.
>
>   [AKA there are lots of calendars to support.]
>
>> This is already a solved problem in the Text Encoding Intiative  
>> (TEI). [ ... ] <date calendar="Julian" value="1732-02-22">Feb. 11,  
>> 1731.</date> [ ... ] We can't change the author's original written  
>> dates, but it would be useful to normalise documents using the  
>> Julian calendar to proleptic Gregorian dates.
>
> Yes, the draft needs to clear up the (mis)understanding that <time>  
> requires authors to place Gregorian dates in the original.
>
> If the calendaric meta information should be available to human  
> consumers, then then @title seems like a better place. The draft  
> could recommend how to use @title for <time>.
>
>
> Aryeh Gregor 2009-03-10 22.37:
>> On Tue, Mar 10, 2009 at 3:48 PM, Andy Mabbett
>>>> How widely - compared to Julian dates - are those published, in  
>>>> the wild?
>>>> You might be tending towards 'Reductio ad absurdum'.
>> There are definitely [too] many non-Julian/Gregorian calendar systems
>  [ ... ]
>> A much saner solution seems to be to say that HTML supports exactly  
>> one type of calendar: in this case, proleptic Gregorian.
>
> Again, this is about the datetime attribute. The draft should stress  
> that the very text content can be in any calendar format.

I agree with that.

>
>
>> Authoring tools can be used to convert from other formats to  
>> Gregorian.
>
> And in that regard, it should be very relevant to have a calendar  
> attribute.

Or reuse the RDFa datatype attribute with new calendar system keywords.

Take care,
Rob

Received on Wednesday, 11 March 2009 08:55:06 UTC