Daylight Saving Time change with an absolute date

问题:

I'm trying to implement correct DST adjustment handling in my alarm clock app. So I'm reading description for DYNAMIC_TIME_ZONE_INFORMATION that I use to retrieve the current DST adjustment information via the GetTimeZoneInformationForYear API, and it says the following:

DaylightDate:

A SYSTEMTIME structure that contains a date and local time when the transition from standard time to daylight saving time occurs on this operating system. If the time zone does not support daylight saving time or if the caller needs to disable daylight saving time, the wMonth member in the SYSTEMTIME structure must be zero. If this date is specified, the StandardDate member in this structure must also be specified. Otherwise, the system assumes the time zone data is invalid and no changes will be applied. To select the correct day in the month, set the wYear member to zero, the wHour and wMinute members to the transition time, the wDayOfWeek member to the appropriate weekday, and the wDay member to indicate the occurrence of the day of the week within the month (1 to 5, where 5 indicates the final occurrence during the month if that day of the week does not occur 5 times).

If the wYear member is not zero, the transition date is absolute; it will only occur one time. Otherwise, it is a relative date that occurs yearly.

I'm also checking the current DST adjustments observed all over the world, and if the relative DST adjustments seem pretty straightforward, I'm not exactly clear how the following adjustments could be conveyed via DYNAMIC_TIME_ZONE_INFORMATION -- with just an absolute month and a day.

For instance:

Egypt
-----
DST Start: May 15
DST End: Last Friday September

or this one:

Iran
----
DST Start: March 21–22
DST End: September 21–22

Does anyone know how to do this?

回答1:

To understand the time zone structures, it helps to look at the Windows registry under the following key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\

Here you'll find all of the built-in time zones of the Microsoft time zone database, which is maintained by Microsoft via Windows Updates.

Let's look at one of the example cases you mentioned:

.\Egypt Standard Time\

.\Egypt Standard Time\Dynamic DST\

From this we can see that there are specific DST rules defined for year 2005-2011. Outside this range, we fall back to the TZI value of the root entry.

You'll notice that there the 2014 entry for Egypt is missing. That's because Egypt gave almost no notice about the upcoming change. You can expect that there will soon be a hotfix from Microsoft available with the update.

The binary data in the registry is deserialized to a REG_TZI_FORMAT structure, which looks like this:

typedef struct _REG_TZI_FORMAT
{
    LONG Bias;
    LONG StandardBias;
    LONG DaylightBias;
    SYSTEMTIME StandardDate;
    SYSTEMTIME DaylightDate;
} REG_TZI_FORMAT;

An issue you should be aware of is that Windows doesn't like time zones that transition right at midnight. The workaround is that instead of saying "00:00 on the last Friday in September", you have to say "23:59:59.999 on the last Thursday in September". However, here you have to be careful because rules like these can sometime lead to erroneous derived dates. To counter that, sometimes each year will have it's own rule. The recurrence-pattern format is still used rather than the fixed-date format, mostly for consistency purposes.

However, there's another problem - This structure can only support two daylight saving time transitions in a year. One at the DaylightDate when DST begins, and one at the StandardDate when DST ends. Since Egypt is enacting DST except for Ramadan, there will be four transitions. This also happened in Egypt in 2010, and also occurs regularly in Morocco. To deal with this design flaw, Microsoft has traditionally released multiple updates, timed to coincide with the changes. (For example, see KB2297272.)

I'll assume Microsoft will push out the multiple-update changes, so for sake of example we'll leave out the Ramadan period. This rule starts DST on the 2nd Wednesday in May at 23:59:59.999 and ends it on the last Thursday in September at 23:59:59.999.

"TZI" = 88ffffff 00000000 c4ffffff 000009000400050017003b003b00e703 000005000300020017003b003b00e703

That corresponds to a REG_TZI_FORMAT structure having these values (as JSON for clarity):

{
    "Bias" : -120,         // Standard offset is UTC+2
    "StandardBias" : 0,
    "DaylightBias" : -60,  // Subtract an hour for DST
    "StandardDate" : {
        "wYear" : 0,       // Recurrence pattern
        "wMonth" : 9,      // September
        "wDayOfWeek" : 4,  // Thursday
        "wDay" : 5,        // Last occurrence
        "wHour" : 23,
        "wMinute" : 59,
        "wSecond" : 59,
        "wMilliseconds" : 999
    },
    "DaylightDate" : {
        "wYear" : 0,       // Recurrence pattern
        "wMonth" : 5,      // May
        "wDayOfWeek" : 3,  // Wednesday
        "wDay" : 2,        // Second occurrence
        "wHour" : 23,
        "wMinute" : 59,
        "wSecond" : 59,
        "wMilliseconds" : 999
    }
}

I think this answer is long enough, so I'll leave it to you to extrapolate the rules for Iran if you like. Though, I'll point out that the Windows data for Iran has been incorrect since 2009 and has yet to receive an update. :-/

As a side note, if you want to specify a fixed date rule, you can provide a non-zero "real" year value. Then the day field represents the actual day - rather than the occurrence. However, this is typically avoided because it only makes sense for the Dynamic DST rules that apply to individual years. It doesn't makes sense to use a fixed-date in the generic TZI entry in the root node.

UPDATE

Microsoft has released an update for Egypt for 2014 in KB2967990.

回答2:

Iran is an odd one in that the DST transition dates don't conform to the normal rules which the Microsoft registry expects. Eg: 2nd Sunday in March. So I agree that you need to use absolute dates but achieved using the registry format. The DST transition date's weekdays vary nearly every year.

Iran DST transition dates are based on the persian calendar https://mm.icann.org/pipermail/tz/2003-March/012053.html

So the dynamic registry method would be the answer with a lot of changes every single year!