Sometimes when sorting the index is the last thing you want to use

by Michael S. Kaplan, published on 2006/12/22 22:15 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/12/22/1350684.aspx


The other day, in response to my post Don't get into the zone too soon...., reader Kevin Dente asked in a comment:

>not that people were scared off by the lack of documentation
>here in the past!

Hmm, yes, it turns out one of our products falls into that category. We have code that reads the time zones from the registry, which breaks on Vista because the "Index" registry entry associated with each time zone no longer exists in Vista. Why the omission? Is there something about the new time zone model that makes the notion of a time zone index invalid?

Just before I had the chance to ask him, Software Design Engineer Robert Doyle answered the question just as someone else asked him about the very same thing. Robert (one of the awesome GIFT Ireland developers who helped provide the Vista updates to clock and calendar) answered the question thusly (right after another dev suggested "I guess that’s what you get for relying on undocumented information in the registry" and someone wanted to know how to sort the entries since they were relying on the index for the sort:

The control panel in Vista sorts the time zones by Bias (descending) - and where biases are equal by Display Name (ascending) in the user’s local language.

@tzres.dll,-571 refers to a multilingual string resource. The MUI_... values were added in Vista to allow time zone names to be presented in the correct UI language.
http://msdn2.microsoft.com/en-us/library/ms725481.aspx

If you are showing a list of time zones to the user please use these in conjunction with RegLoadMUIString().
http://msdn2.microsoft.com/en-us/library/ms776232.aspx

Although I agree with Robert that the index was not a good way to sort the list ever and that using the values for almost anything was probably a bad idea (and that relying on undocumented stuff pretty much does leave one in a bind when the decision comes back to haunt them like this), they are hard to maintain in terms of something useful if one wanted to keep them in order and have the order mean something, since they were sequential yet time zones get added in the middle all the time.

Even so, I admit to being a bit dismayed that the indexes were taken out, though I believe the componentized nature of the new setup kind of led to the change and there is even a chance that I was a dev who did the initial checkin this way (the time zone setup stuff changed hands several times and I had it during an early point when everyone else was busy and Longhorn (as it was called then!) had only one time zone since "that's all we needed to boot" according to one developer....

I vaguely recall being dismayed at the time as well, though I can't remember now if I was dismayed for (a) being forced to do this myself by the architectural constraints or (b) noticing this change was made when I was reviewing it before I did my changes. When I look at it now  they clearly redid it all anyway, so I think it would require the source code control logs and a psychic to divine exactly what happened.

Though this does underscore the importance of not relying on the undocumented. Another day I will tell a story about an application that was hit much harder by time zone issues even more interesting than the index one....

 

This post brought to you by  (U+157e, a.k.a. CANADIAN SYLLABICS QAAI)


Kevin Dente on 3 Jan 2007 8:55 PM:

Michael,

Thanks for addressing my question. Unfortunately, in XP and before this was an area where MS had left us high and dry - ALL timezone enumeration was undocumented, and there was no API. So it's not particularly surprising that picking through through the registry we ended up using some bit of information that wasn't intended to be used and wasn't maintained going forward - there's no way we could have known which parts would and wouldn't be documented eventually.

Some quick googling showed that we weren't the only ones in this boat - looking through those registry keys appears to be a pretty common thing to do. When people have a need, and there's no documented way of doing it, they will inevitably turn to the undocumented.

Michael S. Kaplan on 3 Jan 2007 9:28 PM:

I hear you Kevin, and for what it's worth I wish there had been a better answer for this sort of issue (just like I do for this other one). Though of course there is a risk in relying on the undocumented....

Roger Willcocks on 27 Mar 2008 10:01 PM:

So here's a question then:

How do you record what timezone something is for?

Not what offset, but what timezone?

Brazil and Montenegro have the same offset, but different start/end for DST for example.

Display, Dlt and Std are all presumably changeable.

The MUI values don't help, though you could maybe hack that.

TZI?  Don't think so.

There isn't even a standard DLT/STD code to use for each time zone as far as I can tell.

Michael S. Kaplan on 27 Mar 2008 10:16 PM:

You might want to put this one over in the Suggestion Box -- for a very different post in the future....


referenced by

2008/06/29 Did someone break GetTimeZoneInformation in XP?

2007/10/31 Making things better out from under people: the story of MUI

2007/01/09 The Phantom [Time] Zone

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