夏令时更改为绝对日期 [英] Daylight Saving Time change with an absolute date

问题描述

我正在尝试在闹钟应用中实施正确的DST调整处理。因此，我正在阅读。这也发生在 2010年埃及中，并且经常发生在摩洛哥中。为了解决此设计缺陷，Microsoft传统上发布了多个更新，定时更新以使其与更改一致。 （例如，请参见 KB2297272 。）

我假设Microsoft将推出多次更新更改，因此为了举例说明，我们将省略斋月时期。此规则在DST的5月第二个星期三23：59：59.999开始，并在9月的最后一个星期四23：59：59.999结束。

  TZI = 88ffffff 00000000 c4ffffff 000009000400050017003b003b00e703 000005000300020017003b003b00e703 
  

对应于<$具有以下值的c $ c> REG_TZI_FORMAT 结构（为清晰起见，为JSON）：

  {
 Bias：-120，//标准偏移量是UTC + 2 
 StandardBias：0，
 DaylightBias：-60，//减去一个小时对于DST 
 StandardDate：{
 wYear：0，//重复模式
 wMonth：9，// 9月
 wDayOfWeek：4，//星期四
 wDay：5，//上次出现
 wHour：23，
 wMinute：59，
 wSecond：59，
 wMilliseconds：999 
}，
 DaylightDate：{
  wYear：0，//重复模式
 wMonth：5，// 5月
 wDayOfWeek：3，//星期三
 wDay：2，//第二次出现
 wHour：23，
 wMinute：59，
 wSecond：59，
 wMilliseconds：999 
} 
} 
  

我认为这个答案足够长，所以我将留给您推断伊朗的规则如果你喜欢。不过，我要指出的是，自2009年以来，伊朗的Windows数据一直不正确，并且尚未收到更新。 ：-/

另外，如果要指定固定日期规则，则可以提供非零的实际年份值。然后，日期字段代表实际的日期-而不是发生的日期。但是，通常避免这样做，因为它仅对适用于各个年份的动态DST规则有意义。在根节点的通用 TZI 条目中使用固定日期是没有意义的。

更新

Microsoft已在 KB2967990 。

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?

解决方案

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.

这篇关于夏令时更改为绝对日期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！