It’s just data

The <time> element

The WHATWG Web Applications 1.0 Working Draft defines a time element, which is intended to contain a date and/or a time in an international date, formatted in a way that is only a slight superset of RFC 3339.

I can imagine how in the future that can be handy for spiders and for rendering localized or accessible content in the future, but for now the best that can be done is to emulate some of that via JavaScript.

I’m trying it out on my weblog.  Previously, dates were displayed in EST/EDT, but now they are initially displayed in GMT/UTC, and subsequently localized to your local preferences.

I’m not aware of anybody elese doing similar things, with or without the use of the <time> element.  If anybody knows of any such uses, or even other deployed applications of the <time> element, I’d appreciate it if you left a pointer in the comments.


The funny thing about blogs, though, is that you generally don’t care exactly what instant an entry is made. If you refer to the timestamp at all, it’s more likely to be to find out what time it was for the author, since that may have impacted what was said. For example, if I make an entry in my blog at 1am on a Friday night you may assume that I was under the influence of alcohol and that is why I’m rambling on.

Now I have no point of reference on your blog to work out what your wallclock time was when you made this entry, because you’re timestamped in UTC. I don’t know what timezone you’re in (though I can guess EDT given what you’ve said in this entry), so I can’t just “do the math” for myself, nor can my browser help me by giving me the option of displaying in your local time.

I’m not sure what the solution is. Having a machine-readable “timezone this was written in” in the HTML would be one solution, but that sort of thing can cause problems for blog software as it’d need to keep track of the timezone for each entry to avoid it all going horribly wrong due to Daylight Savings or trips abroad.

Posted by Martin Atkins at

Microformats define <abbr title="YYYYMMDDTHH:MM:SS">(any format you like)</abbr> as a common pattern for dates (I don’t think there’s any common way to mark a date, except to use the appropriate class name for the microformat that happens to be interpreted as a date, like dtreviewed.

Posted by Ian Bicking at

Now I have no point of reference on your blog to work out what your wallclock time was when you made this entry

Now we are even.

Posted by Sam Ruby at

Microformats define [abbr title="YYYYMMDDTHH:MM:SS"](any format you like)[/abbr] as a common pattern for dates (I don’t think there’s any common way to mark a date, except to use the appropriate class name for the microformat that happens to be interpreted as a date, like dtreviewed.

Posted by Ian Bicking at

I was involved in this discussion which resulted in Mike West’s PerfectTime.js. 

Mike ended up using the Microformat-style <abbr> pattern to mark up the dates/times.  It works well without needing a new element defined.

Posted by Daniel Morrison at

If there’s one thing we need for time on web sites, its a standard for popup date selectors. I was costing out ticket costs last week, and all the dialogs on the airline’s own web sites suck for selecting dates three months in advance. Expedia is the best, even on firefox. A standard, popup date selector, please!

Posted by Steve Loughran at

The PerfectTime object Daniel mentions was an extension of some work that _why did, which in turn was based on Johan Sundström’s AJAX × Date × Time × Time zones - best practices.  Reading through the discussion on those articles is probably worth your time.

As for the `time` element, I get that it’s semantically valuable.  But for the moment, the Microformat makes a lot of sense to me, and solves the problem in a pretty straightforward manner.

Posted by Mike West at

In response to Martin Atkins:
I think it’s quite important to have both. Something that is totally driving me nuts in Mail.app is that it somehow fails to properly sort emails from different time zones. I’m not sure if the email’s time zone stamps are broken or Mail.app (didn’t investigate), but I end up seeing first the response, then the question on mailing lists. It’s quite surprising to see this in 2007, especially as they do have time zone issues in the US, so you might assume that this gets fixed faster than other typical i18n problems.

Posted by Martin Probst at

I for one am really excited to see all of the new semantic elements being defined in HTML 5.

I sincerely hope the Yahoo! YUI people are working out how to choose between Javascript-generated controls and native controls for applications that want to use them (since I think the YUI library is among the best cross-browser javascript libraries out there today).

There’s a nice evolution taking place on the web nowadays: people use Javascript and HTML to define controls that are useful and eventually these controls get replaced by native elements in the next version of the markup language.  It’s happened before (eg. marquee) and it’s a good way to progress I think.  Microformats are nice and all, but having native elements will provide that many more semantic niceties for indexing and parsing.

Posted by Josh Peters at

I’m not aware of anybody elese doing similar things, with or without the use of the <time> element.

Hixie has been doing it for years.

Posted by Henri Sivonen at

Yeah, I had something similar on my blog thanks to Typo.  It’s gone now as a side-effect of the switch to Mephisto though.

Posted by Bob Aman at

[from billyg] The < time > element

I’m trying it out on my weblog. Previously, dates were displayed in EST/EDT, but now they are initially displayed in GMT/UTC, and subsequently localized to your local preferences....

Excerpt from del.icio.us/network/DragonI at

Typo indeed does something similar.  Perhaps even better.

Hixie’s server is not responsive at the moment.  I’ll try again later.

Posted by Sam Ruby at

And, indeed, Hixie too.

Posted by Sam Ruby at

I dislike it. A lot. I’m seeing your dates (day of the week and name of the month specifically) in dutch (as those happen to be the local settings on this computer I’m working on at the moment (just here for a contract job)), on a page that’s otherwise completely in English, and which I expect to be completely in English, as my local settings at home have time displayed for the New Zealand locale (one of the few English locales with time settings that make actual sense).
It’s a stumbling block, making me do painful mental switches. It’s nearly as bad as Google showing all labels on blogger in dutch for weblogs that are otherwise completely in English (though that’s worse, as they select it based on my ip, and ignore all attempts to override it with http_accept_language (while that works for non-english languages)</rant>).

And what Martin said in the first comment. I read weblogs because I care about (what) the author (has to say). Local datetime is a useful piece of metadata about that. How it relates to me personally is very much irrelevant - you the author didn’t consider me when you were writing the content either, after all.

Posted by Sander at

One of the things I find fascinating about this whole discussion is that while the times I displayed previously were in my local timezone, they were completely without any metadata: example.

Posted by Sam Ruby at

FWIW, I think displaying the local time is a nice usability win. I don’t really care what time it was in your timezone when people said things and I certianly don’t know enough personal information about most bloggers to infer things like “oh it’s 1am Saturday, he must be drunk”. I am interested in questions like “how long ago was this entry/comment written?” which are much easier to work out without having to do timezone conversions (possibly after guessing the timezone being used on the site in question).

Posted by jgraham at

I’m with the people that think this is a good idea. If I received an email from you, the time would be in my local timezone and locale. If I read your blog in my RSS reader the time I saw would be local too. Why should it be any different if I’m viewing a post from you in my browser? Without localization, dates can often be meaningless. If I saw a post dated 05/06/07 what is that supposed to mean to me? AFAIC the sooner all dates and times are localized, the better.

Btw, there seem to be some weird differences in how the various browsers are interpreting your code. For example, in Firefox 2.0.0.3 this post is dated “17 April 2007 19:35:42”. In Opera 9.02 it shows as “17/04/2007 19:35:42”. Those are essentialy my long date format and my short date format respectively. In IE 7 it’s “TUE 17 APR 2007 AT 18:35” in small caps. Also its font is much bigger than Firefox and Opera (actually slightly bigger than the title) and left aligned rather than right aligned.

Posted by James Holderness at

When I encounter a date in an English language web page, I expect the date to be written in English and formatted according to English (language) customs.

I’m not really going to weigh in on the time-zone issue, but the hap-hazard mix languages and date-formatting throws me off as a reader.

Posted by Már at

For example, in Firefox 2.0.0.3 this post is dated “17 April 2007 19:35:42”. In Opera 9.02 it shows as “17/04/2007 19:35:42”. Those are essentialy my long date format and my short date format respectively.

What you are seeing is whatever toLocaleString returns.

Posted by Sam Ruby at

What you are seeing is whatever toLocaleString returns.

Yeah I realised that. I took a peek at your code. I just thought it was interesting that IE wasn’t returning a localized date, both in terms of formatting as well as the timezone (we’re at GMT+1 in the UK at the moment).

Posted by James Holderness at

I just thought it was interesting that IE wasn’t returning a localized date

At the moment, the script isn’t running at all on IE as it doesn’t support document.addEventListener.  Safari/WebKit doesn’t currently support onDOMLoad.  I’ve seen code that emulates these functions (via polling on Safari) and a combination of conditional comments/document.write/script defer/readyState on IE, but haven’t investigated further.  So currently, all users of such browsers get non-localized dates.

Posted by Sam Ruby at

Personally my preference would be that the time be localised to my timezone, but displayed in either a neutral format, or one appropriate to the site’s content.

Where I am responsible for the content, I tend to use “Mmm DD, YYYY” as the date format (where “Mmm” is the three-letter month name abbreviation). This is unambiguous and can be understood independently of any local cultural conventions.

I also use 24-hour times, since people used to 12-hour times can read them directly (even if they find them unfamiliar), whereas the interpretation of 12AM/PM in 12-hour times is not inherently obvious to people used to 24-hour times. (Personally, I still have to look up which is which, every time.)

Something like “Apr 19, 2007 (16:48)” is universally accurately comprehensible.

Posted by Aristotle Pagaltzis at

links for 2007-04-18

What Is RDF? “What Is RDF” was originally written by Tim Bray in 1998 and updated by Dan Brickley in 2001. Recently it seemed like time for another update, particularly to relate RDF and the Semantic Web to the cutting edge of web...

Excerpt from All in a days work... at

Sam Ruby: The <time> element

[link]...

Excerpt from del.icio.us/tag/samruby at

Sam Ruby: The element

The WHATWG Web Applications 1.0 Working Draft defines a time element, which is intended to contain a date and/or a time in an international date, formatted in a way that is only a slight superset of RFC 3339. Comment at Faves | View original page...

Excerpt from Faves: alan.dean at

Add your comment