(imported comment written by SystemAdmin)
I haven’t seen any word from MS yet. The below post came from the Patch Management Listserv. The orginal regfix was short - but it has since been revised to include numerous entries. Reason I posted the question was to hear if you might have something in the works. Quite often BF adds a fixlet for things that may not be in the normal Microsoft Update Release site - but are considered very important. Wanted to get a head start on if I might need work on something myself. But again, I would assume MS has got something in the works.
Patchmanagement Listserv Post:
(I tried mailing this correction to the list Thursday evening, but it
must have gotten lost, possibly due to the attachments it originally
had. So instead, if you want the dst2006.txt and dst2007.txt files
mentioned below, please e-mail me off-list.)
Cliff Hafen pointed out a very serious shortcoming in the previously
suggested registry fix, namely that changing the system’s time zone will
cause the fixed DST rules to be overwritten. He noted five other
registry values that also need to be changed, which I’ve included in the
following .reg file text. The same disclaimer from before necessarily
applies here, too.
================
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\Alaskan Standard Time]
“TZI”=hex:1c,02,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02
,\
00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\Central Standard Time]
“TZI”=hex:68,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02
,\
00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\Eastern Standard Time]
“TZI”=hex:2c,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02
,\
00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\Mountain Standard Time]
“TZI”=hex:a4,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02
,\
00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones\Pacific Standard Time]
“TZI”=hex:e0,01,00,00,00,00,00,00,c4,ff,ff,ff,00,00,0b,00,00,00,01,00,02
,\
00,00,00,00,00,00,00,00,00,03,00,00,00,02,00,02,00,00,00,00,00,00,00
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
“DaylightStart”=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00
“StandardStart”=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00
================
This will modify the current DST start and end time rules, and also
update the rules associated with each of the five US and Canadian time
zones that will adopt the new Daylight Saving Time in 2007.
For the curious, the structures within the TZI registry values are
SYSTEMTIME structures rather than TIME_FIELDS structures, and as such
have the “weekday” as the third field rather than the eighth.
Otherwise, the interpretations of the two types of structures are the
same.
Two SYSTEMTIME structures appear within each TZI value: the structure
for the time zone’s “DaylightStart” rule is at offset +000Ch, and the
structure for its “StandardStart” rule is immediately after it, at
offset +001Ch.
Since line wrap will almost certainly butcher the above .reg stuff, with
the moderator’s permission, I’ve attached two text files [DS: not
attached, e-mail me off-list instead for these files] that basically are
.reg files, except you’ll need to remove the text “(delete-this-part)”
from each, and rename each to have a .reg extension.
dst2007.txt implements the above registry changes, switching the
system’s concept of US and Canadian Daylight Saving Time to the 2007
version. It should only be applied AFTER Monday, November 6, 2006, and
only to computers in US and Canadian time zones that will observe the
new Daylight Saving Time definition.
dst2006.txt restores the current (2006) rules for Daylight Saving Time.
Of course, this registry fix shouldn’t be used as a substitute for the
Microsoft patch, but should instead only be used on systems where there
is no alternative. Once the Microsoft patch does come out, further
registry changes might be necessary on unpatchable systems to achieve
compatibility with their patch’s changes (for instance, if Tijuana is no
longer going to be included in the US/Canadian Pacific Time zone). But
hopefully this registry fix, as it stands now, will be good enough for
most of the people who need it.
Thanks again Cliff, and sorry everyone for the oversight…
-----Original Message-----
From: Derek Soeder
mailto:dsoeder@eeye.com
Sent: Thursday, October 12, 2006 12:34 PM
To: Patch Management Mailing List
Subject: US Daylight Saving Time 2007 registry fix
Hey y’all, here’s a registry change you can implement AFTER Monday,
November 6, 2006 (I’ll explain this below), to change a system’s
Daylight Saving Time start and end rules. To use it, just copy the text
below into a .reg file, open it using Regedit, then reboot the system.
Disclaimer: I have not thoroughly tested this, and neither I nor eEye
guarantees its fitness or promises to support it, so use it at your own
risk. That said, I believe it will work for you, but please test it
first on a small scale and tell me how it turns out.
================
REGEDIT4
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
“DaylightStart”=hex:00,00,03,00,02,00,02,00,00,00,00,00,00,00,00,00
“StandardStart”=hex:00,00,0b,00,01,00,02,00,00,00,00,00,00,00,00,00
================
This registry modification will change the DST start time to 2:00 AM on
the second Sunday in March, and the DST end time to 2:00 AM on the first
Sunday in November.
Now for my favorite part – how it works.
The format of these two registry values is a TIME_FIELDS structure,
which consists of eight two-byte fields: Year, Month, Day, Hour,
Minute, Second, Milliseconds, and Weekday. In this particular case,
Year is disregarded, and Day isn’t the number of a calendar day, but a
count of weekdays. For instance, a 1 the Day field corresponds to the
1st Xxxday, while a 5 would correspond to the 5th Xxxday, or the last
Xxxday if there aren’t 5 in the specified month.
Here I’m using Xxxday to represent the day of the week specified by the
Weekday field. Its value ranges from 0 (Sunday) to 6 (Saturday). As
expected, the Month field’s value ranges from 1 (January) to 12
(December). The Hour, Minute, Second, and Milliseconds fields are
regarded and should be set to indicate 2:00:00.000 AM as the cutover
time.
So applying this breakdown to the above registry data, we see that
DaylightStart takes on the following values:
Year … 0 (unused)
Month … 3 (March)
Day … 2 (the second Sunday in March)
Hour … 2 (2:00:00.000 AM)
Minute … 0 (")
Second … 0 (")
Milliseconds … 0 (")
Weekday … 0 (Sunday)
While StandardStart takes on these values:
Year … 0 (unused)
Month … 11 (November)
Day … 1 (the first Sunday in November)
Hour … 2 (2:00:00.000 AM)
Minute … 0 (")
Second … 0 (")
Milliseconds … 0 (")
Weekday … 0 (Sunday)
Because the Year field is disregarded, Windows will think that these
rules apply to every year – past, present, and future – so that’s why
it’s important to apply this registry modification only AFTER Monday,
November 6, 2006. Once you apply the change and reboot, Windows will
find the first Sunday in November of the current year (this year, that’s
November 5, 2006), and regard that as the DST end time. This creates a
period of time between October 29, 2006, and November 5, 2006, which
Windows will improperly regard as falling within Daylight Saving Time.
If you apply the registry modification to a system whose date and time
land within this period, expect some improper behavior.
Any time between Monday, November 6, 2006, and Saturday, March 10, 2007,
should be fine for applying this registry change.
Well, that’s all I can think to write about this; please let me know if
you have any questions or observations.