Re: [whatwg] Times, dates, and related topics

Ian Hickson wrote:
> The primary use cases for <time> are:
> 
>  * The ability to encode 80% of dates and times in a machine-readable way 
>    so that the user can make use of them in an automated fashion, in 
>    particular for adding dates to a calendar.
> 
>  * The ability to restyle dates that contain a "day" component so that 
>    they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000).

For this to be possible, we would need a new mechanism for it in CSS.

>  * The ability to encode the output of <input type=date> and <input 
>    type=time> in an unambiguous fashion, for styling.

Why is the ability to encode the output of <input type=month"> is excluded.

>> There are numerous reason to use dates which are not very precise, but 
>> are still precise nevertheless. I'm going to release the new version of 
>> my current project in <time datetime="2009-04">April</time> but I cannot 
>> tell as of now the exact day of the release.
> 
> Why do you need the <time> element at all here?

In this case, in the absense of any other contextual information, the 
time element clarifies for the user that it's talking about April 2009, 
rather than whatever the current year may be when they read it, assuming 
the UA exposes that information in some way).

>> From my understanding of the current draft, the earlier date that can be 
>> used is 1970-01-01. The Unix epoch. Why that limit?
> 
> You can use any date in the Gregorian calendar, as well as any date up to 
> 1AD in the proleptic Gregorian calendar. I'm not sure where you saw a 1970 
> limit; could you point to that part of the spec so it can be fixed?

I suspect the misconception may have come from the fact that the Unix 
epoch is used for the Date object returned by the DOM APIs.  I'm not 
sure how to make the spec clearer on this.

>> - If content is missing, print 'datetime' attribute (in a friendly way, if
>> desired and set by user, or simply as is if unable to do better)
> 
> We could do this too, I guess. What do browser vendors think? Is replacing 
> the contents of <time> with a locale-specific rendering if the element is 
> empty or the attribute missing something that is acceptable?

I think if we were to do this, we would have even more need to be able 
to format dates and times with CSS, especially so that authors can 
override the browser default.

It's also seems like something that would be difficult to get right. 
Consider, for example, a user is reading a site in English, but their 
native language, and thus their system language, is Norwegian.  The page 
says:

<p>The event is on <time datetime="2009-03-29"></time>.</p>

To render that in a human readable format, should the browser render 
"The event is on 29 March 2009" or "The event is on 29 Mars 2009" (where 
"Mars" is the Norwegian word for March).  The latter would be easier to 
do based on the user's system settings.  The former would depend on the 
browser knowing the language of the page, which is not always reliably 
available.  The other alternative is to simply render it in a numerical 
only format, and the only unambiguous alternative is to render the 
ISO-8601 date as: "The event is on 2009-03-29".

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Thursday, 19 March 2009 10:55:10 UTC