hCalendar and timezones
I was thinking that hCalendar might be helpful for helping with timezones. The basic idea, just like, ecmanaut says, is to send the zone information in GMT and let the browser do the conversion. So I’m thinking if we use the microformat for dates, hcalendar, then the date gets formatted as,
<abbr class="dtstart" title="2006-05-01T12:15:03.0Z">5:15am</abbr>
where the “title” attribute is machine readable and in GMT, and the body is human readable and in, presumably, the time zone of the page author. All that’s needed is a script (or greasemonkey plugin) like this one that walks the DOM, finds these hCalendar fragments, and replaces the time in the users timezone into the human-readable part of the date. So,
5:15am
gets displayed,
5:15am
Ok… but there are a couple of problems. The first is the formatting has changed. The resolution to this would be to write a function that deduced the format from the example, and then fills in that format with the local timezone. Seems doable, at least in a way that works 80% of the time (and fails gracefully with a generic date format). The second is that the intent of the time has, in fact, been changed a little bit. The user needs to know that this has happened (the greenish background is a hint at that), and needs to be able to see the original string to compare. The user might also prefer to see the data formatted as the author intended, but to be able to hover over the date and see it transformed into his own timezone. This also seems doable.
karl said,
May 12, 2006 @ 2:32 am
Even better if you do that, really simplify it. Right now there are two issues about this.
[abbr class=”dtstart” title=”2006-05-01T12:15:03.0Z”]5:15am[/abbr]
title is for accessibility. It helps to have a better understanding of the content. In the microformat use it’s becoming the opposite. In a sense, this would be more logical in terms of accessibility
[abbr class=”dtstart” title=”5:15am”]2006-05-01T12:15:03.0Z[/abbr]
but then it would go against the microformat principles of making it readable.
The second issue is that it doesn’t respect the DRY principle. There is a redundancy of information and then it’s prone to errors when we update it. For example, someone with a wysiwyg tool.
I would rather prefer something like that:
[span class=”dtstart tz-Z time”]5:15am[/span]
And then the rest of javascript needed to make it right in display and processing.
Peter Krantz said,
May 17, 2006 @ 2:57 pm
One idea could be to provide parsers with the format used in the element value. Datetime constructs are typically standardized in writing anyway (you may even have a national standard).
So, instead of trying to squeeze in data in an attribute which isn’t meant to hold it (e.g. title) one could do like this:
[span class=”dtstart MMM-dd-yyyy”]Dec 24 2007[/span]
Of course this creates other problems (e.g. how to represent other characters while maintaining valid values for class names). Maybe some more research should be done to see if this works.
But, we follow DRY and do not abuse the title element.