Yesterday when I finally got a chance to look at mail I found the following in my inbox:

Michael,

The following is from a post in the microsoft.public.vc.language managed newsgroup; I wasn't sure where else to put it. A person by the name of Jochen Kalmbach suggested I contact you.

Just a few comments with regard to the new Microsoft design of how DST info is stored (for certain time zones), after applying the update KB928388 (http://www.microsoft.com/downloads/details.aspx?familyid=2D0ECBBC-FE8F-4BFC-8667-C1D46662B5B7&displaylang=en).

For those who are not familiar with what the update KB928388 does, here is some info:
http://support.microsoft.com/default.aspx/kb/928388.
http://www.microsoft.com/windows/timezone/dst2007.mspx

After applying the update the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones registry info is updated but a new way of storing the DST (Daylight Saving Time) information has been implemented for time zones where the DST may change from one year to another (e.g. the DST is changing dramatically for 2007 in the US and all US timezones where DST is observed are affected). The new design is interesting. However, after applying the update GetTimeZoneInformation is now returning the DST values for 2007, even though the year is 2006 (tested Windows XP SP2). This affects UTC dates that fall within the four week period (represented by the change in DST between 2006 and 2007) for dates that are converted from that period from UTC to local time (or visa versa). Essentially, these dates are one hour off when converted using the TIME_ZONE_INFORMATION returned via the GetTimeZoneInformation API.

Questions:

  1. I understand that Windows Vista has a new API named GetDynamicTimeZoneInformation, that is designed to return the new DST info implemented in KB928388. Will Windows Vista return the DST info for the actual current year using this API?
  2. If we have to convert a UTC to local time for a year other than the current year (not considering the 2006/2007 bug after applying KB928388), it now makes sense that we should have at least two new APIs that allow you to pass in the "year" that we want the TIME_ZONE_INFORMATION (or DYNAMIC_TIME_ZONE_INFORMATION ) for. Example:

    DWORD GetTimeZoneInformationEx(
      WORD wYear,
      LPTIME_ZONE_INFORMATION lpTimeZoneInformation );

    DWORD WINAPI GetDynamicTimeZoneInformationEx(
      WORD wYear,
      PDYNAMIC_TIME_ZONE_INFORMATION pTimeZoneInformation );

Thanks.

Well, to start with this is just the kind of scenario that dynamic time zones in Vista are there to help out with!

The fact that there is no historical information stored in prior versions is just the way Windows was designed, so the reported problem (especially in prior versions like XP) is by design since attempting to get historical time zone information once the time zone information has changed is simply not possible.

But the design of dynamic time zones is such that the Vista versions of the existing GetTimeZoneInformation/SetTimeZoneInformation functions will continue to work as is, even though the results that GetTimeZoneInformation will return can in fact change from year to year (and the registry will contain the changing information as described in the DYNAMIC_TIME_ZONE_INFORMATION topic (the new struct is used by the GetDynamicTimeZoneInformation and SetDynamicTimeZoneInformation topics).

One could argue (as Michael has, above) that new functions are needed to get and perhaps even set the values for another year beyond the current one. Though I have trouble seeing the actual need, since in the current design we are instructed that the wYear member of both the StandardDate and DaylightDate SYSTEMTIME stucts must always be 0. So why not make a future extension to the existing function(s) that allows one to set the wYear member appropriately if one wants the results of as specific year in a dynamic time zone?

This is not what happens here in Vista now but the updated semantic could be simple -- the whole structure has to be zeroed out, and if it is then the struct becomes an inout struct and the wYear member will then represent the year (according to the semantics of the SYSTEMTIME struct, of course).

More importantly, perhaps in the future TzSpecificLocalTimeToSystemTime and SystemTimeToTzSpecificLocalTime could do something special here in the face of an actual date with a year in it, when running on Vista in a dynamic time zone?

And of course absent such functionality either in Vista or in an update one could still look in the registry, where this information has now been officially documented for the first time ever (not that people were scared off by the lack of documentation here in the past!). So even if none of the above works then one still has the tools in Vista to get the right answer.

The argument one could make in the meantime is that the update described in KB928388 should not be installed until one is ready and willing for the change to happen.

 

This post brought to you by ᧠ (U+19e0, a.k.a. KHMER SYMBOL PATHAMASAT)