ISO 8601 is asinine

From the I Can't Believe Michael Said That Out Loud files....

A few years ago, Aimee Mann was talking about the song Long Shot from her album I'm With Stupid:

There are at least four songs on it that I wrote for myself and said, 'It's fine. This will never get on the album anyway.' 'Long Shot' was one of those and lo and behold, it's the single. You don't put words like 'You fucked it up' into a song if you want it to be a single. But that line had to be there; it had to have that sound of colloquial dismissiveness.

So perhaps I should not have ISO 8601 is asinine as the title of my post. But that title has to be there; I had to have that sound of not entirely colloquial dismissiveness? :-)

(I also do really like Long Shot by the way, though only live -- mostly because when it is performed live there is a very awesome Julian Coryell electric guitar solo at the end which is just a serious rocking-out fest that you can close a show with. An entirely irrelevant and off-topic point but it must be said because Julian is an awesome guitarist!)

I'll put up the Wikipedia link on ISO 8601, although who knows what that will say tomorrow. :-)

But anyway, I was reading the other day in the SQL Server 2005: CLR Integration blog, in Isaac K. Kunen's post Best Week Ever. Isaac explained one of examples of a difference between what SQL Server 2005 does and what ISO8601 says:

Unfortunately, SQL Server defines the first week of the year as the week in which 1 January lies.  (Some of us would argue that this makes more sense, but ISO 8601 says what ISO 8601 says.)

What's a poor database developer to do?  Wait until the next release of SQL Server?

Why do we have this preconeived notion that if it is an ISO standard, it is better? There are lots of times that this is not the case, and this standard especially is one of them.

Why? I'll tell you. Because what it tries to do as a standard is to regularize many aspects of dates/time handling that actually vary depending on the location in which you sit. That is why the GetLocaleInfo function has an LCTYPE representing the first week of the year (LOCALE_IFIRSTWEEKOFYEAR) with one of the following entries in it:

and another LCTYPE representing the first day of the week (LOCALE_IFIRSTDAYOFWEEK) with the following entries in it:

The date behind these same two LCTYPE values are the ones used for DateTimeFormatInfo's FirstDayOfWeek and CalendarWeekRule properties.

The simple issue is one of respect -- respecting the fact that in different places there are different preferences. How can someone ignore those preferences?

One could argue that the problem is not with the international standard that steamrolls over those preferences, it is with the products that it used where it should not be. But that ignores the fact that people like to follow international standards, even in cases such as this one where it makes them look like lemmings going right off the cliff of common sense.

Off the top of my head I cannot recall if SQL Server follows a LOCALE_IFIRSTWEEKOFYEAR-esque solution or is hardcoded to use the '0' entry in our locale data -- so I am not sure if they need a little work here, too. I'll give it a try at some point to find out for sure, if someone else does not report back on this point first! :-)

Now there are other examples in ISO 8601 that do the same sort of regularization of something that is truly different in different locales. And the W3C uses it to try to reduce complexity and errors which is a great goal unless it causes a de facto cultural imperialism of sorts by forcing people to change the way they think about software.

I may be inviting with my provocative viewpoint a whole host of fans of the ISO 8601 standard to complain about why it is so crucial that this standard exist, so let me mention ahead of time where my biggest problem is with it -- that it tries to be human readable in so many cases. If it is human readable than it ought to prefer user preferences for locales. If ISO 8601:

• only tried to define a binary standard, and
• removed all of the pieces that did not forward the binary standard, and
• did not struggle to point out those various attempts at better human readability, and
• if it strongly discouraged people from plugging in the various pieces in the way that Isaac was implying SQL Server ought to in a future version, and
• if it worked harder to point out how wrong it is to misuse it in so many of these other contexts

then perhaps I would not mind it as much. Then I would just focus on the people misusing it.

But in its current form, it is just too easy to misuse in software products in the name of conformance to standards. Even when doing so makes the standard look bad, and the software products look worse....

This post brought to you by "Ƨ" (U+01a7, a.k.a. LATIN CAPITAL LETTER TONE TWO)