This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I read through the specification for the time element and it seems that there are two use cases that apply: 1) Mark some text as a date in a machine-readable format, so that it can be easily integrated with a calendar. 2) Provide a date in a machine-readable format that will be translated to a locale-specific date for display to the user. The specification does not mention the format to be used for (2), so one would assume it will be decided by the UA and the values will vary widely for different UAs in different countries. I believe this would make it difficult for content authors to properly mark up their articles. For example, I wish to stress that a given date was a Saturday, I might write: ... on Saturday <time datetime="2010-08-07">7th August</time> A UA might choose to display the date as follows: ... on Saturday Sat 7th Aug 2010 Furthermore allowing the browser to alter the display value prevents the website providing relative times such as today, 1h ago, last week and such for recent dates. The browser would not be able to do this itself and thus I would write: <time pubdate datetime="2010-08-07" /> yesterday separating the date from the human-readable value and breaking (1). As a result of these two examples, I think it would be wise for browser not to provide locale-specific dates as they damage the ability of content authors to display times in the way they wish.
I agree that this is not useful to have in the spec. Unpredictable display is evil. If users want this functionality, there's nothing to stop implementers from making it opt-in via preference, extension, etc. Cases where it would be a bad thing: 1) Page is in English, but you're using a Chinese computer, so the dates and only the dates display in Chinese. 2) When looking at a date like 6/7/2010, to figure out whether it means June 7 or July 6, you now have to not only try guessing whether the author is American or British, but also whether they used <time>, and if so whether your browser thinks *you* are American or British. On the other hand, I don't see a real need this is addressing. Generally speaking, the format of dates will be written in the same locale as the rest of the page, so if the user can understand the page, they can probably understand the date too.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: We used to have it so that if you provided textual content, it wouldn't replace it. People complained and said it should always replace it. Really I would just like to use CSS for this, but CSS doesn't yet support replacing an element with content that is a formatted date or time. At this point I don't really know what to do. If we make it do nothing, then people will get the datetime attribute's value wrong all the time since it will be hidden metadata.
(In reply to comment #2) > We used to have it so that if you provided textual content, it wouldn't replace > it. People complained and said it should always replace it. Where? Replacing automatically is a really bad idea in practically all circumstances, IMO. Have you checked with any implementers to see if they'd even consider replacing? > At this point I don't really know what to do. If we make it do nothing, then > people will get the datetime attribute's value wrong all the time since it will > be hidden metadata. But even if browsers were willing to replace the contents (which I personally doubt), old browsers still wouldn't, so authors would refuse to use the contents anyway for years to come. Even if datetime isn't specified and the contents are in the wrong format, the element is still useful -- <time pubdate>September 12, 2010</time> encodes more information than without the <time>. You need a natural-language date parser to extract it, but practically speaking those are readily available for English, at least (e.g., strtotime() in PHP). As far as I can see, the biggest use of <time> is pubdate and the biggest use of that is to give info to search engines (which can afford natural-language date parsers in practice) about machine-generated pages (a large proportion of which are generated by a small number of software packages that are reasonably likely to get hidden metadata right). So I don't think it would be a huge issue if authors used datetime="" and got it wrong a lot -- <time> would still be pretty useful. I don't think that asking browsers to replace the contents with a localized time makes sense at all.
If pubdate was the only value, I think we'd drop this altogether. The main value is machine-readable dates that don't require natural-language processing. I would like to make sure we expose the attribute somehow, so that it's not hidden metadata. At the end of the day, I'll spec whatever gets implemented. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: What will browser vendors implement? Convince them to do what you want and that's what the spec will say. In the meantime, I don't want to keep flip-flopping on this so I've left it as is.
Okay, I guess we'll just wait for implementers.