When do time zones and cultural settings get updated?

by Michael S. Kaplan, published on 2005/05/28 02:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/05/28/422806.aspx

Yesterday, Jeff Parker post a comment to a non-post about time zones and backcompat from Larry Osterman (Larrys blog is so cool that he has ideas pop up even when he only posts about the fact that he could do put up anything substantive since he was working on an internal presentation!). Jeff's comment was:

In case you were thinking that this is proof that you should read the comments in people's posts, this post would do the trick, since I saw it before Larry sent me email about the other issue. :-)

The issue of backcompat and time zones that Jeff brings up is an interesting one (and the news that Indiana plans to join the rest of the country is fascinating, now if we could just get Arizona to follow suit!). In this specific case, lots of people never even knew about the Indiana rules until an episode of The West Wing had some fun with it. But for the time zones in Windows, the principles are easier to decipher:

Now what to do in future versions is a different story -- it is easy enough to migrate people when they upgrade, when/if you need to. There are, after all, at least 75 different time zones the last time I have had cause to look at them all, last year. More get added from time to time, both for good reasions and bad (I will not make judgments or cast dispersions by giving you my own opinions on categorizations here -- let's just say that neither common sense nor maturity always figure into official policies or requests!).

The issues of supporting a time zone "slot" past its useful life as a distinction for the sake of backwards compatibility is an fascinatingly dufficult issue, one that I am glad I do not have to make.

For myself, I usually do not change my time zone settings even when I travel -- it is easier for me to just do a little math in my head; if everything goes wrong and I miscalculate, maybe I can get out of a few meetings! :-)

Now the principles here also very much apply to locale/culture settings. They must be updated to match cultural expectations. If you have code that either does not query it or code that assumes it will not change, the code is just wrong....

Shameless plug: you could use my WorldClock app - http://www.codeproject.com/dotnet/worldclock.asp. There's a bit of nasty registry-slurping there as I couldn't find an API for querying the time zone database.

I wondered for a long time why the system maintains the BIOS clock in local time, not in UTC. Obviously there are compatibility reasons - DOS used to run the clock in local time, and most system setup utilities have no concept of time zones either. Linux fans often advocate running the system clock in UTC - after all, UTC is an ever-increasing clock while local time has odd jumps in it, if the local time zone features daylight savings.

But there's a hidden problem there - what happens if the rules change? Suddenly you'll be committing the sin of not showing the actual time as perceived by the user. If the user corrects it, is permitted to correct it, this machine's idea of UTC may be different from others in the same network, which could affect Kerberos authentication for one (since packets only have a short lifetime to help prevent replay attacks).

Actually this affects both storing the time in UTC and storing it in local time. In the first case the displayed time is derived from the stored time and UTC offset; in the second, UTC is derived from the stored time and the offset. If the time zone table says UTC offset is X and daylight savings has additional offset Y between given dates, but the political reality is different, you get problems.

We've traditionally used UTC for time computatins because of its supposedly invariable nature, but political reality may intervene.

I had another brush with this recently when implementing an SNTP client for Windows CE (it's a component in the OS, but the specific platform did not include that component). The 'obvious' implementation is to call SetSystemTime, since NTP provides times in UTC, but Windows CE's automatic clock update logic seems to have problems if the transition from the previous 'current time' to the new 'current time' crosses multiple DST boundaries - sometimes it will not increment the clock when it should, leaving the time wrong by an hour. I believe the implementation actually runs clock.exe using a registration similar to the CeRunAppAtEvent API when the system clock is changed, but this discards important information - was the clock set with SetSystemTime or with SetLocalTime?

My solution was to turn off the automatic update feature, perform the conversion myself (I forgot about or was unaware of FileTimeToLocalFileTime) then call SetLocalTime to set the clock. The update happens once an hour; for the specific application it doesn't matter if the clock is slightly wrong around the DST transition periods. The application is actually for a scheduled application upgrade feature - we need the local clock to be correct so that the scheduled task occurs at the right time.

I wish instead of selecting timezone - people select a longtitude / latitude of their current location.

Thus - it will be possible to calculate correct date time for any event in the past or any event in the future.

Regaring time zone for my location (Kyiv, Ukraine) a lot of people was using wrong time zone for a years until Microsoft added it in Windows XP.
Actualy I've requested it to be added in Windows 2000 - but somebody has decided that 3 lines change in one of setup*.inf files (I've listed requered change in my bug report) will cost more for Microsoft then benefits provided to users.