Time, How I Loathe Thee

Grace Hopper once said that "The wonderful thing about standards is that there are so many of them to choose from.". How true it is for time and dates as well. To name just a few off the top of my head:

• RFC 822/2822
• RFC 3339
• ISO 8601
• UTC
• TAI
• Unix Time
• Java Time

And there are lots more.

I know that is it too much to ask that we all agree on how we want the time displayed on our screen, or how it is to be printed on a newspaper. But surely we, as a computing community, can come to agreement on a couple things about data transmission and parsing:

1. If it is machine readable, the machine can format it nicely for a human
2. If it is machine readable, it should be easily machine readable. I don't want to have to build a compiler to parse a date/time.
3. No redundancy. If it tells me the month is "Oct" but it lists it as "9", which one is right?
4. Numbers only please, not localization issues
5. No timezones. The machine doing the local formatting can also do the offset to the local time.
6. Ability to encode sub-seconds

The best I've seen for this is the RFC 3339 spec. However, it too has its flaws. Within the ABNF, it is setting us up for the Y10k problem ;). The 'T' and 'Z' characters "may" be in lower case. Why? You are also allowed to -- "for the sake of readability" -- use a space instead of the 'T' as a separator. Why?

If you want to have optional parts of the format, fine. I'm open, for example, to using "2007-01-27" to represent today without having to specify a time. However, I think it is stupid to author a new standard that has the aforementioned flaws. The added complexity to any parser needed is not that great, but it is entirely unnecessary.