When do time zones and cultural settings get updated?

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:

• We update any time the time zones update -- the rules are such that correctness is more important than consistency. There are applications that do not use the APIs to match the behavior, but the average user will usually blame the application, not the operating system (in fact they might wish that the OS had easier updating methodology!).
• Once the Indiana time zone is the same as its surrounding area, the fact that it has a separate time zone 'slot' is more of a cosmetic issue. It cannot ever be removed in existing products even if the settings in the zone are updated. After all, while time zones change, the zone itself is a setting on peoples' machines and removing it can cause a lot more problems then it would solve. There is no hurry to do it, if you ask me; given the contention surrounding the issue, it may end up getting reversed at some point anyway (say if Troy Woodruff loses his seat and legislators' remorse sets in, parts of the old rules could find their way back in Indiana!).

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)