The Phantom [Time] Zone

by Michael S. Kaplan, published on 2007/01/09 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/01/09/1438044.aspx

I did receive another question after the discussion in the comments of that post:

Now I could point out that a Windows 2000 machine with latest updates has something like 74 time zones while a Windows XP machine has more like 85 and Vista has more like 83.

Or I could point out that time zone definitions also change all the time, so that even if two machines have as time zone they may not have the same definition (especially since not every updates the same things!).

Or maybe I could point out that plenty of people run tools like tzedit and modify their time zones for whatever reason, good or bad.

Or perhaps I could allude to the fact that people hae been able to create custom time zones that would be unaware of this arbitrary system.

Or I could mention the whole issue with the changes that are in Vista that keep the registry from needing to store localized names as static registry data anyway.

Or I could sugges that all of the supported methods of managing time zone settings and changes do not depend on this value in Vista.

Or I could point out that until Vista this data was undocumented and subject to change (which it finally did).

But to be honest, I don't think I want to point out any of these things. At least not in that way.

So let me stick to the simple engineering issues that one can distill from all of these facts. Like that any application that ignores all this and tries to use the information as if it were consistently available and consistently the same across all machines has a design flaw that someone really need to look into fixing. There simply is no unique index that can be used here, and an application that is assuming there is has pretty much always been on borrowed time.

This is hardly why the indexes went away. For what it's worth, my original guess was wrong, it had more to do with those "ultimately unsupportable" arguments which come into play here (and the confusion that unsupportabled values and using them can led to).

Well, one could certainly package the binary TZI data, which is supported in the sense that if you have it, you can stick it in calls that take a TIME_ZONE_INFORMATION and do things with it since it tells one how to change settings.

If my machine says a particular event happened at a certain date and time that maps to a particular UTC date and time, then I honestly don't give a fig what time someone else's machine thinks it is. Every single attempt to map it on another machine that assumes what the other machine has can accurately describe the event as it occurred for me is simply wrong. If everyone is lucky, the wrongness may just be an hour, but there are plenty of nuances that can increase or decrease that across the span of possible times.

Because in the end there are two choices: either the time zone is unimportant (in which case one can just use UTC), or it does matter (in which case it really ought to be accurate).

Although to be honest, if one really wants to store the time I did something then why not just store the two values for the local and UTC time? If one needs more data then storing the TZI data will do the trick.

Doing it all with that [now defunct, and never so great] index is definitely not a good answer....

I'm really thinking I should pull my CodeProject article at http://www.codeproject.com/dotnet/worldclock.asp. No Vista complaints as yet, but I'm afraid I can't be bothered to fix it.

Well, you could always put in a note that says "doesn't run with Vista" on it? :-)

I'd like to point out the tz database again: http://www.twinsun.com/tz/tz-link.htm

If you REALLY need timezone information, this is the BEST source. To be honest, the timezone information that Windows keeps is just *good enough* to satisfy the needs of Windows itself (which aren't many, frankly).

As far as I can tell, the tz database is updated far more often than Windows' database (several times a year, compared to how often in Windows?) and it also includes historical data (if you need that).

This year, 2008, O&E s database is on the eighth version, letter i. All but a small handful of changes are a matter of official acts, changes in local time-keeping law.

Note that the aforesaid link points to ftp://elsie.nci.nih.gov, and explains how to unpack the files.

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.