Monday, June 2, 2008

Html Time

UPDATE - It appears that this IS actually in HTML 5 (and was before this post - I am not the instigator of this)! Sweet! Finally something well engineered out of the W3C!

<Time />

Why not? Has anyone given this idea any thought before?

Here is the problem. I have a blog (in fact, this is true...I'm writing in it now...how...exocentric...). Each of my posts is tagged with a time. This time means something to me, since I set it in Blogger to be Mountain Standard Time sans Daylight Savings. But it doesn't mean much to the user, unless I

  1. Tell them that I used that timezone somewhere, like the sidebar
    -or-
  2. Post all times in a format which includes the timezone, like ISO 8601 (2008-06-02T00:20:31.52-07:00 anyone?)

Obviously the first solution is lame, since I now have to explain something I otherwise should not have to, while the second solution is just not readable by humans (3l33t h4xorz may technically be humans, but, while they can probably read this without effort, they are too busy watching Star Trek, and so they do not count). That leads me to one solution. Since I clearly do not want to explain to my users what time zone it is in, the simple solution is to automatically put it in the correct time zone for users.

There are three solutions here, and I will order them in order of how lame they are.

Solution 1: Server Side Script

Build a server side engine to render your time based on the user's time preferences. The problem is, you have to have a user in the first place. I have thousands of many people visiting this blog who are not blogger users, and don't have a Google account. What about them? I could try to detect the time using javascript, but then I would be better off with...

Solution 2: Client Side Script

Using Javascript, I can render a date object as a string, and retrieve the timezone offset data I need. The two functions of interest are Date.toLocaleString() and Date.getTimezoneOffset(). The former is simpler and easier to use, while the latter allows for complete control over the outputting format (since it outputs only the offset, one could easily then apply the returned offset to the origional value and print the result out manually using the properties as desired).

The problem with this method is it uses Javascript. I do not mind using javascript. This particular issue, however, is

  1. Fairly simple
    -and-
  2. Fairly consistant

This makes it a perfect candidate for encapsulation. This leads me to:

Solution 3: The DateTime Tag

Introduce a new HTML tag in version 5 called DateTime. DateTime is, well, a date and a time. By defualt, Time could be formatted two ways, verbose and compact. The basic form might be:

<datetime>
    <day>2</day>
    <month>6</month>
    <year>2008</year>
    <hour>0</hour>
    <minute>51</minute>
    <second>2</second>
    <timezoneoffset daylightsavings="false">-7</timezoneoffset>
</datetime>

Obviously, this is quite verbose, but it is also very readable and simple. An alternative form could be:

<datetime>2008-06-02T00:51:02.00-07:00</datetime>

This form would be perfect for machine generation and reading, but is less readable. Clients could probably easily support both, however, especially the later, since ISO 8601 is already the standard for XML.

This would also have several other benifits besides time-zone relevance.

First, by expressly defining a data-structure, we allow user agents to immediately identify it. Where you can quickly and easily provide advanced functionality with images, you can provide similar, and equally cool, functionality with dates (like 'Create New Appointment at this Time').

Search Engines can index pages better, since they provide automatic temporal metadata. Search improves - a page which lists only one date tells the engine a lot. Say that date was from 1995, and the page is clearly about programming. What are the chances that this is a modern article, versus some Unix geek's first website?

Finally, and perhaps most importantly, users can choose how best to represent time. Lots of us have personal preferences for time display (I personally like DOTW DD, MM/YY - HH:MM:SS), and we could each set our respective browsers to display it as we like. Heck, we could even come up with really cool custom displays, like analog clock images, or binary, or....you know where this leads.

Date and time are a very simple datatype, and should be treated as such. We have a structure for lists, specifically so we don't have to make a bunch of custom formatted spans and put manual bullets up front. We have headers, paragraphs, etc. Why not times? And why stop here? Why not also add other data types as well? Addresses would be nice (think automatic maps), any other good ideas?

As I don't have the time, and the W3C does not have the ears to listen, I'm not going to submit this suggestion. But, should anyone who the W3C might actually listen to find it interesting enough to submit, feel free to do so. Let me know, and I will be happy to support it and talk about it more, so long as I am not speaking to a deaf wind.

No comments: