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:

Hey I was thinking of something about your backwards compatability and how long should you keep API's. Maybe when you get time you could elaborate on another situation with that. This year Indiana has voted to go along with Daylight Savings Time. Where previously they did not. Microsoft even has a Eastern (Indiana) Time Zone. Now would this go away? Why would you keep it? And more importantly are they going to patch it since there is no longer and Indiana time zone. What does Microsoft do if an API specifically affects a culture and the culture changes.

Just a suggestion, something I am curious about. Since I went to Purdue I know a lot about the old Indiana time. When I heard they were changing I was wondering how a shift like this would affect API's and do they still then remain valid.

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....


This post brought to you by "¿" (U+00bf, a.k.a. INVERTED QUESTION MARK)

# Maurits [MSFT] on 28 May 2005 9:10 AM:

That's disappointing. I was sort of hoping the rest of the country would come to its collective senses and abandon DST.

Of course, there's still a part of me that hopes for a day when everybody uses UTC ;)

# Mike Dimmick on 28 May 2005 9:35 AM:

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.

# TheMuuj on 28 May 2005 9:56 AM:

YES! UTC for all! Daylight savings time for none!

I'm getting pretty good and mentally translating UTC to and from CST/CDT (-06:00/-05:00). I don't see why everybody couldn't just learn to use UTC internally and rid us of cofusing time zones.

In England, people could go to work from 8:00 to 17:00. Here, I'd go to work from 14:00 to 23:00. I would be happy, but I'm sure most people would have difficulty adjusting.

So maybe I need to take over the world and force the issue. *evil grin*

# AT on 28 May 2005 10:25 AM:

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.

# Michael S. Kaplan on 28 May 2005 11:28 AM:

Hi, AT --

I kind of hinted at the problems with the first idea in the other time zone post -- a significant number of people would assume that it was part of an evil Microsoft plot to track the locations of its customers. :-)

I will talk more about the second and third ideas in future posts....

# Maurits [MSFT] on 28 May 2005 9:40 PM:

The "other part of me" then realizes that having the day change in the middle of a meeting is just weird. :)

Maybe I'll lobby for the US to finally adopt the metric system first. GM going bankrupt removes one major stumbling block.

# TheMuuj on 29 May 2005 12:07 AM:

Maurits: If we were all on Flex time, that might not be an issue. I work better at night, anyway. Maybe I should move to the Arctic for part of the year.

Actually, I believe that the New York subway systems change the official date at 3:00AM instead of midnight. Midnight does seem a tad too early to me to begin a new day.

# Edward on 31 May 2005 3:25 AM:

I think you mean Aspersions not Dispersions.

# Michael S. Kaplan on 31 May 2005 6:41 AM:

This post contains many nonsklarkish English
flutzpahs, but the overall pluggandisp can be glorked from context.

(apologies to DH!)

# Jeff Parker on 31 May 2005 12:24 PM:

Hah, thanks Mike I just went back today to read the comments on Larry's post. Nice thing about RSS Bandit the flag for follow up feature like in outlook allows me and reminds me to go back and check out comments.

Anyway thanks for the explanation. I am hoping it doesn't get overturned and they join the rest of the world. I do wonder how many pieces of software would be affected by this for people that thought it would neve change. I know there are tons of old bank software and other things that this could affect.

# chris on 2 Aug 2005 5:03 PM:

you can vote for which time zone is best for Indiana at www.gopsjc.com...Eastern is currently ahead but only by a few votes.

referenced by

2006/05/24 Did somebody say time zones were intuitive?

go to newer or older post, or back to index or month or day