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,


gets displayed,


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.


2 Responses to “hCalendar and timezones”

  1. 1 karl
    May 12, 2006 at 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.

  2. May 17, 2006 at 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: