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
Last month, after I posted Sometimes when sorting the index is the last thing you want to use, in response to a question from Kevin Dente.
I did receive another question after the discussion in the comments of that post:
Hi Michael. Sorry to bug you, but I was wondering if you might have a suggestion on how we might best go about fixing the time zone issue that we were discussing in blog comments. We are currently using the now-deprecated TimeZoneIndex value as a language independent time zone identifier that gets written in XML messages sent between systems (the message contains a timestamp in UTC and the tz identifier of the sending system). Is there another value that we can use to uniquely identify the time zone - preferably one that's independent of the localized version of Windows thats installed on the sending system?
I thought this one was already answered, but we can dig in agin, I suppose. :-)
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).
So how to solve the problem?
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.
Such an app will also give more intuitve results! I'll explain....
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....
This post brought to you by ∄ (U+2204, a.k.a. THERE DOES NOT EXIST)
# Mike Dimmick on 9 Jan 2007 5:43 AM:
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.
# Michael S. Kaplan on 9 Jan 2007 12:51 PM:
Well, you could always put in a note that says "doesn't run with Vista" on it? :-)
# Dean Harding on 9 Jan 2007 5:42 PM:
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).
# Halasz, Sandor on 8 Dec 2008 8:02 PM:
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.
go to newer or older post, or back to index or month or day