Did someone break GetTimeZoneInformation in XP?

by Michael S. Kaplan, published on 2008/06/29 13:21 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/06/29/8667900.aspx

If anything was ever going to change that was going to break some specific behavior while trying to fix the larger problem that

and suddenly problems seem more likely -- and I'll take this bug report as more authoritative (off the top of my head) than assurances that no such bug exists. :-)

I'll forward this blog and the forum note to some of the time zone movers/shakers to see if anything pops....

Hi Michael,

Thanks for the shout-out.

Here's a minimalistic repro case, should someone feel the urge to try it:

#include <windows.h>
#include <iostream>
using namespace std;
static const char* RetvalNames[] = {
"TIME_ZONE_ID_UNKNOWN",
"TIME_ZONE_ID_STANDARD",
"TIME_ZONE_ID_DAYLIGHT"
};

int main(int argc, char* argv[])
{
   TIME_ZONE_INFORMATION tzi = {0};
   DWORD retval = GetTimeZoneInformation(&tzi);
    cout << "Return value: " << RetvalNames[retval] << " (" << retval << ")" << endl;
    cout << "Daylight start month: " << tzi.DaylightDate.wMonth << endl;
    cout << "Standard start month: " << tzi.StandardDate.wMonth << endl;
}

It should say:

Return value: TIME_ZONE_ID_UNKNOWN (0)
Daylight start month: 0
Standard start month: 0

When we originally had this problem, I checked on Vista (pre SP1, I think) and it worked as expected. Haven't checked other platforms.

Cheers,
- Kim

Boy does this sound familiar! I already ran into these problems 7 years ago, and nothing has changed it seems.

My first assumption was that turning off automatic DST adjustment would do only that: stop Windows from automatically adjusting my system clock when switching from DST and back.

When I turn the automatic adjustment off I don't change timezones and the same DST rules are therefore still valid, so I expected Windows would still know about DST even with the automatic adjustment switched off.

In practice it completely disables DST, causes GTZI to return bogus data and its behavior doesn't follow the official documentation anymore.

I happened to have access to Microsoft support at the time (Win2k days), and the answer I got was that "the internal structures do not have a boolean that says that daylight is enabled/disabled. All they carry are some strings and time values, so to "disable daylight" you set the daylight and standard to the same values."

So for me this weird behavior is not recent, since it has been broken since Win2k (so including XP); it actually only worked right under Windows98 :-/

At the time I already asked for a documentation update since GTZI returning TIME_ZONE_ID_DAYLIGHT the whole year round with bogus transition dates is just wrong and doesn't match the documentation, as mentioned by Kim. But apparently nothing happened since...

But for me the main problem is that disabling the automatic DST adjustment impacts GTZI for no good reason.

The on-line help for the automatic DST adjustment setting still says "If you use more than one operating system, make sure that only one of them automatically adjusts for daylight saving time."

What it doesn't tell you is that disabling the adjustment in Windows has nasty side-effects...