(2003 to 2005)


Mon Nov 1 13:48:00 UTC+1100 2004


I say string based representations of temporal information for co-ordinating or time-stamping activities which require granularity no less than one second should be in this form: yyyy-MM-dd-HHmmss

If I have anything to do with it this particular format always implies UTC. (Guaranteed after 2004-11-01-143247 until further notice ;) 

I don't believe the format is used commonly by other international standards. Less potential for ambiguity. Bonus.

It uses a heavily limited character set, including no alphabetical or white space characters. Compact. Compatible (with modern file systems and URIs without need for character escaping). Easy to identify, parse and validate. Bonus.

It is an atomic value. It does not try to include localized representations of a week part (i.e. 'day') or timezone information. Data integrity. Simplicity. Bonus.

It is universally relevant. Non ambiguous. Identifiable heuristics. MEANING == point in UTC time. Bonus.

It's good for another ~8000 years. Durable. Bonus.

It's more 'human readable', and less ambiguous than “yyyyMMddHHmmss“. Bonus.

It is fixed width and sorting on its alphabetical representation in all known (to me) character encodings will be equivalent to a value based sort. Similar to advantages inherent in the ISO 8601 standard. Handy. Bonus.

It's open to the possibility of extension, to forms such as “yyyy-MM-dd-HHmmss-nnn“, “yyyy-MM-dd-HHmmss-nnnnnn“, etc. Where any granularity of time could be expressed. Bonus.

It does not identify the timezone relevant to the generator of the value. I consider timezone information inconsequential for the stated purpose of this representation of time. The value can be reliably migrated to any timezone, and the timezone of the generator, or any other applicable timezone, can be expressed separately in a message or inferred from a 'business rule'.

I say it's THE ONE TRUE WAY to express a string based representation of a point in time with granularity of one second.

(As opposed to a point in time relative to a non-identifiable or non-UTC clock, time of day, or a time of month, or a time of year, or a range thereof, which are an entirely different kettle of fish, useful only to feeble human minds with the confused notion that the universe revolves around them.)

In short, I consider this representation to imply its TYPE as a “temporal value relative to a known forward-only clock: UTC” in addition to expressing its VALUE.

And now, just thinking out loud, I reckon the format “yyyy-MM-dd HHmmss” could be used to describe a temporal value relative to an unknown (or otherwise unspecified) and not necessarily forward-only clock. Hmm.. maybe.

I wish someone maintained a international standard for describing 'clocks' with an integral representation.. perhaps someone does?

In my view, timezone information should be left out of temporal representations altogether, and there should be two basic notions, one of time relative to UTC and one of time relative to 'something else'. If you've ever had a call centre operator request a time from someone in another timezone, then you know my pain...

Copyright © 2003-2005 John Elliot