Unofficial Time Zones Update (Testers wanted)

Cool! Just saved me some time! Thanks!

I'll probably do it anyway, g.

--

Gary S. Terhune
MS-MVP Shell/User

"John John" wrote in message
...
PCR wrote:
Gary S. Terhune wrote:
| I'll update what I've said thus far by saying that I don't know for
| sure that those last instructions are necessary to NT/2K *OR* 9x
| systems.

Neither do I, but, as John John said... If Time/Date Properties were
used to advance the date, then clicking OK to that filled the other
Registry key...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation

I'm thinking, if DOS was used, then...

(a) Something like NisTime could have done it.
(b) What was the prior EST date?
Whatever... likely it was passed too!

I did a fresh, clean install of Windows 98SE to test this and I can
confirm that the time changes will NOT happen unless the contents of the
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation]
are refreshed to reflect the changes made in the
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time Zones]
keys.

I did regsnaps of the key in question, applied Gary's fix and rebooted. To
do the test I rebooted and adjusted the time and date in the BIOS. After
rebooting, the time did not change at the new DST ordered date and time
without doing additional steps to have Windows update the information in
the registry. To have Windows reload the key I simply clicked on the
Toolbar clock "Adjust Date/Time" and just clicked once on the up/down ??
time adjust arrow, just one simple click to get the applet to activate and
offer the "Apply" option. Clicking on "Apply" forced Windows to reread
and load the correct information in the key. Only after doing this step
did the time advance as expected at the right date and time.

Clicking the "Apply" button in the Date/Time applet caused Windows to
update 2 values in the CurrentControlSet key:

----------------------------------
Values modified:2
----------------------------------
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
00 00 0A 00 00 00 05 00 02 00 00 00 00 00 00 00
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
00 00 0B 00 00 00 01 00 02 00 00 00 00 00 00 00
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
00 00 04 00 00 00 01 00 02 00 00 00 00 00 00 00
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00

----------------------------------
Total changes:2
----------------------------------


John

John John wrote:
| PCR wrote:
| Gary S. Terhune wrote:
| | I'll update what I've said thus far by saying that I don't know for
| | sure that those last instructions are necessary to NT/2K *OR* 9x
| | systems.
|
| Neither do I, but, as John John said... If Time/Date Properties were
| used to advance the date, then clicking OK to that filled the other
| Registry key...
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation
|
| I'm thinking, if DOS was used, then...
|
| (a) Something like NisTime could have done it.
| (b) What was the prior EST date?
| Whatever... likely it was passed too!
|
| I did a fresh, clean install of Windows 98SE to test this and I can
| confirm that the time changes will NOT happen unless the contents of
| the
|
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation
]
| are refreshed to reflect the changes made in the
| [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time
| Zones] keys.
|
| I did regsnaps of the key in question, applied Gary's fix and
| rebooted. To do the test I rebooted and adjusted the time and date
| in the BIOS. After rebooting, the time did not change at the new
| DST ordered date and time without doing additional steps to have
| Windows update the information in the registry.

OK. I was thinking, even if BIOS was used to advance the date, there may
have been values in this key (the old values) that STILL would be passed
& trigger the time change when Windows started. I see somehow that did
not happen, but I am loath to do the calculations why, even if I could
remember the old dates. Of course, left to their own workings & a normal
click of the clock, they would trigger things at the wrong date anyhow.
SO...

I am well satisfied it IS NECESSARY to get the fit/proper values in
there. I see Terhune still will test it himself. OK, then.

| To have Windows
| reload the key I simply clicked on the Toolbar clock "Adjust
| Date/Time" and just clicked once on the up/down ↑↓ time adjust
| arrow, just one simple click to get the applet to activate and offer
| the "Apply" option. Clicking on "Apply" forced Windows to reread and
| load the correct information in the key. Only after doing this step
| did the time advance as expected at the right date and time.

OK. That's good to know that any click on "apply" of that requestor
would cause the whole tab to recalculate & save its data, whether a
particular box was changed or not. OK, thanks.

| Clicking the "Apply" button in the Date/Time applet caused Windows to
| update 2 values in the CurrentControlSet key:
|
| ----------------------------------
| Values modified:2
| ----------------------------------
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| 00 00 0A 00 00 00 05 00 02 00 00 00 00 00 00 00
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| 00 00 0B 00 00 00 01 00 02 00 00 00 00 00 00 00
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| 00 00 04 00 00 00 01 00 02 00 00 00 00 00 00 00
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| 00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00
|
| ----------------------------------
| Total changes:2
| ----------------------------------
|
|
| John

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR

Gary S. Terhune wrote:
| 1. I don't see how NisTime can update DST or even TZ info, since it's
| TZ agnostic. The info provided is time/date GMT, period. Your own PC
| has to account for the proper offset from GMT and whether it's DST or
| STD, etc.

Yea. I take that back. It might adjust the time & leave a bad date, yea.

| 2. I don't know what DOS has to do with it, either. Windows updates
| the BIOS date/clock according to it's needs. DOS has no concept of
| DST, etc., Yes, you can set the BIOS date/time using DOS, but there's
| nothing automatic about it.

I was saying, using DOS would avoid the Date/Time Properties requestor &
avoid filling that TimeZoneInformation key.

| 3. I'll probably have more answers by morning. Have managed to
| install VPC here and am insomniac.

Alright. Although I am well satisfied that key is important & must be
filled, it could be worthwhile for you to test it as John John did. But
it's up to you to make the calculations as to whether the older values
in that key would trigger the change anyhow after the clock is pushed
ahead that way! John John didn't publish his!


| --
|
| Gary S. Terhune
| MS-MVP Shell/User
|
| "PCR" wrote in message
| ...
| Gary S. Terhune wrote:
| | I'll update what I've said thus far by saying that I don't know for
| | sure that those last instructions are necessary to NT/2K *OR* 9x
| | systems.
|
| Neither do I, but, as John John said... If Time/Date Properties were
| used to advance the date, then clicking OK to that filled the other
| Registry key...
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation
|
| I'm thinking, if DOS was used, then...
|
| (a) Something like NisTime could have done it.
| (b) What was the prior EST date?
| Whatever... likely it was passed too!
|
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| Should things get worse after this,
| PCR
|

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR

On Feb 17, 12:48 am, "Gary S. Terhune" wrote:
I'll update what I've said thus far by saying that I don't know for sure
that those last instructions are necessary to NT/2K *OR* 9x systems.

I don't know what you mean by "pre-NT" systems. There are 9x systems (from
95 through ME) and NT systems (NT4 through Vista -- at least I'm fairly
certain that Vista still qualifies as an NT system.) Not sure about pre-NT4,
since I'm not familiar with the progression of that genre. I think of these
Windows systems being distinct from earlier versions because they have
32-bit processing (and now, 64-bit), the Registry, and Virtual Mode.

In the case of the Time Zones issue, the only important distinction between
NT and 9x is the location of the Time Zones Key in the Registry. Otherwise,
they're the same -- until you get to XP and 2K3 and Vista, where they have
now added mechanisms where the Time Zone changes of the future can be built
in. The previous systems remain static and require manual updating during
the period just prior to when they take affect.

I'll try to test the issue this weekend of whether the updating truly
requires messing with the Dime/Date applet or not, or whether a reboot is
even necessary (though in most cases, these systems require fairly frequent
rebooting, anyway.) I'll see what is necessary to update the
CurrentControlSet key(s). Otherwise, it may have to wait until the first
part of the week.

Note that there is no "blog" involved. I post an article on my website with
no feedback mechanism other than direct email to me, and include a Readme in
the download that has instructions in addition to the article. That's it.

I was confusing grystmill with the blog gristmill. Hence, my
references to a blog.

Further discussion can be found in this and the other Win98 groups (until/if
I decide to broadcast its existence to other Windows groups.)

--

Gary S. Terhune
MS-MVP Shell/User

"tom" wrote in message

oups.com...



On Feb 6, 9:37 pm, "Gary S. Terhune" wrote:

Is that applicable to pre NT systems?

Did you update the blog on this? I cannot find anything.

I am trying to patch a bunch of systems.

What exactly do you have to do on which versions, other than simply
running the
patch .bat file?

I used the patch on a 98SE system, and tested it. It worked for the
March 11, 2007
change. I did not have to do any extra steps, I just ran the bat
file. But, am I missing something?

Thank you. Forgot to add that info to the instructions.

--
Gary S. Terhune
MS MVP --
Shell/Userhttp://grystmill.com/articles/cleanboot.htmhttp://grystmill.com/artic...

"John John" wrote in message

...

I don't know for W9x but for NT/2000 you have to refresh the users Time
Zone information at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation

with the new information contained in the updated database at:

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

It can be done programatically or by changing the Time Zone settings to
a different zone then back to the proper zone. The information there
is
the one that will make the time changes on the proper day and it was/is
entered/copied there at the time that you select(ed) the time zone, if
it's not refreshed the time change will not happen as expected.

Fromhttp://support.microsoft.com/kb/914387

[quote]
Windows time zones

Windows stores time zone information in two locations in the registry.
The first location is the time zone database in the following registry
subkey:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones

The time zone database contains the configuration data for all time
zones in Windows. Windows and other applications use the data to
calculate local times.

The second location for time zone information is the following registry
subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation

Control sets in Windows store system configuration information such as
drivers and services. The TimeZoneInformation registry subkey in the
current control set contains the configuration data for the time zone
that Windows is currently using. Windows copies this information from
the time zone database when the time zone is selected.

[End quote]

John

Gary S. Terhune wrote:

The mod should work fine, so long as the Time Zones key in NT is in
the
same
location as in 2000, and the Values are named the same, etc. The BAT
file
should have created a TZ_BAK.reg file in the %windir%. If that
doesn't
exist, something's wrong. If it does exist, could you please send me
that
file, so I can reassure myself that the original structure looks like
I
think it should look.
gryst_at_grystmill.com

THANKS!!!- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

Terhune hasn't bothered to test, since others have done the deed
satisfactorily. I've updated the instruction files.

What I need to do is make certain that MS didn't actually change any of the
actual data in the keys with the latest patch. I will also shell out the $50
necessary to make this thing self-executing.

--

Gary S. Terhune
MS-MVP Shell/User

"PCR" wrote in message
...
John John wrote:
| PCR wrote:
| Gary S. Terhune wrote:
| | I'll update what I've said thus far by saying that I don't know for
| | sure that those last instructions are necessary to NT/2K *OR* 9x
| | systems.
|
| Neither do I, but, as John John said... If Time/Date Properties were
| used to advance the date, then clicking OK to that filled the other
| Registry key...
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation
|
| I'm thinking, if DOS was used, then...
|
| (a) Something like NisTime could have done it.
| (b) What was the prior EST date?
| Whatever... likely it was passed too!
|
| I did a fresh, clean install of Windows 98SE to test this and I can
| confirm that the time changes will NOT happen unless the contents of
| the
|
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation
]
| are refreshed to reflect the changes made in the
| [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time
| Zones] keys.
|
| I did regsnaps of the key in question, applied Gary's fix and
| rebooted. To do the test I rebooted and adjusted the time and date
| in the BIOS. After rebooting, the time did not change at the new
| DST ordered date and time without doing additional steps to have
| Windows update the information in the registry.

OK. I was thinking, even if BIOS was used to advance the date, there may
have been values in this key (the old values) that STILL would be passed
& trigger the time change when Windows started. I see somehow that did
not happen, but I am loath to do the calculations why, even if I could
remember the old dates. Of course, left to their own workings & a normal
click of the clock, they would trigger things at the wrong date anyhow.
SO...

I am well satisfied it IS NECESSARY to get the fit/proper values in
there. I see Terhune still will test it himself. OK, then.

| To have Windows
| reload the key I simply clicked on the Toolbar clock "Adjust
| Date/Time" and just clicked once on the up/down ↑↓ time adjust
| arrow, just one simple click to get the applet to activate and offer
| the "Apply" option. Clicking on "Apply" forced Windows to reread and
| load the correct information in the key. Only after doing this step
| did the time advance as expected at the right date and time.

OK. That's good to know that any click on "apply" of that requestor
would cause the whole tab to recalculate & save its data, whether a
particular box was changed or not. OK, thanks.

| Clicking the "Apply" button in the Date/Time applet caused Windows to
| update 2 values in the CurrentControlSet key:
|
| ----------------------------------
| Values modified:2
| ----------------------------------
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| 00 00 0A 00 00 00 05 00 02 00 00 00 00 00 00 00
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| 00 00 0B 00 00 00 01 00 02 00 00 00 00 00 00 00
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| 00 00 04 00 00 00 01 00 02 00 00 00 00 00 00 00
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| 00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00
|
| ----------------------------------
| Total changes:2
| ----------------------------------
|
|
| John

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR

OK, s.

--

Gary S. Terhune
MS-MVP Shell/User

"tom" wrote in message
oups.com...

I was confusing grystmill with the blog gristmill. Hence, my
references to a blog.

"Gary S. Terhune" wrote in message
...
| Terhune hasn't bothered to test, since others have done the deed
| satisfactorily. I've updated the instruction files.
|
| What I need to do is make certain that MS didn't actually change any of
the
| actual data in the keys with the latest patch. I will also shell out the
$50
| necessary to make this thing self-executing.
|
| --
|
| Gary S. Terhune
| MS-MVP Shell/User


Not sure what you meant by the "$50.00" for self-executing, but you might
check out other installation alternatives, such as via WinRar, or UPX, or
other free exe creating programs wherein you could create the installation
routine.

--
MEB
http://peoplescounsel.orgfree.com/
BLOG - http://peoplescounsel.spaces.live.com/ Public Notice or the "real
world"
http://groups.google.com/group/the-peoples-law?hl=en - discussion group for
general aspects of Law verses the Peoples' of the world

"Most people, sometime in their lives, stumble across truth.
Most jump up, brush themselves off, and hurry on about their business as if
nothing had happen." Winston Churchill
Or to put it another way:
Morpheus can offer you the two pills;
but only you can choose whether you take the red pill or the blue one.
_______________

|
| "PCR" wrote in message
| ...
| John John wrote:
| | PCR wrote:
| | Gary S. Terhune wrote:
| | | I'll update what I've said thus far by saying that I don't know for
| | | sure that those last instructions are necessary to NT/2K *OR* 9x
| | | systems.
| |
| | Neither do I, but, as John John said... If Time/Date Properties were
| | used to advance the date, then clicking OK to that filled the other
| | Registry key...
| |
| HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation
| |
| | I'm thinking, if DOS was used, then...
| |
| | (a) Something like NisTime could have done it.
| | (b) What was the prior EST date?
| | Whatever... likely it was passed too!
| |
| | I did a fresh, clean install of Windows 98SE to test this and I can
| | confirm that the time changes will NOT happen unless the contents of
| | the
| |
| [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation
| ]
| | are refreshed to reflect the changes made in the
| | [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time
| | Zones] keys.
| |
| | I did regsnaps of the key in question, applied Gary's fix and
| | rebooted. To do the test I rebooted and adjusted the time and date
| | in the BIOS. After rebooting, the time did not change at the new
| | DST ordered date and time without doing additional steps to have
| | Windows update the information in the registry.
|
| OK. I was thinking, even if BIOS was used to advance the date, there may
| have been values in this key (the old values) that STILL would be passed
| & trigger the time change when Windows started. I see somehow that did
| not happen, but I am loath to do the calculations why, even if I could
| remember the old dates. Of course, left to their own workings & a normal
| click of the clock, they would trigger things at the wrong date anyhow.
| SO...
|
| I am well satisfied it IS NECESSARY to get the fit/proper values in
| there. I see Terhune still will test it himself. OK, then.
|
| | To have Windows
| | reload the key I simply clicked on the Toolbar clock "Adjust
| | Date/Time" and just clicked once on the up/down ↑↓ time adjust
| | arrow, just one simple click to get the applet to activate and offer
| | the "Apply" option. Clicking on "Apply" forced Windows to reread and
| | load the correct information in the key. Only after doing this step
| | did the time advance as expected at the right date and time.
|
| OK. That's good to know that any click on "apply" of that requestor
| would cause the whole tab to recalculate & save its data, whether a
| particular box was changed or not. OK, thanks.
|
| | Clicking the "Apply" button in the Date/Time applet caused Windows to
| | update 2 values in the CurrentControlSet key:
| |
| | ----------------------------------
| | Values modified:2
| | ----------------------------------
| |
| HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| | 00 00 0A 00 00 00 05 00 02 00 00 00 00 00 00 00
| |
| HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| | 00 00 0B 00 00 00 01 00 02 00 00 00 00 00 00 00
| |
| HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| | 00 00 04 00 00 00 01 00 02 00 00 00 00 00 00 00
| |
| HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| | 00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00
| |
| | ----------------------------------
| | Total changes:2
| | ----------------------------------
| |
| |
| | John
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| Should things get worse after this,
| PCR
|
|
|
|
|

One minor issue. I think that if someone runs the patch twice on the
same system they will wipe out there backup recovery file. So if
someone intends to run it twice for some reason then they should
rename the backup file. But maybe this is too obvious.

On Feb 3, 6:11 pm, "Gary S. Terhune" wrote:
OK, I think it's mostly finished. All I need are a few guinea pigs, web page
proofers, etc. The files I am offering work for ALL legacy Windows systems,
95 through 2000 (XP and 2003 are the only ones MS provides updates for, and
the info is already in Vista.)

The only system I haven't tested yet is NT4. If anyone has one they're
willing to test it on, I'd sure appreciate it. Otherwise, it will be another
several days before I can dig out my copy of that and load it into a VPC.

Might as well start at the beginning:http://www.grystmill.com

Once I'm satisfied, I'll be broadcasting the news to all MS public
newsgroups. Heck, I bet even most XP users don't know they need it, and it
isn't installed by Automatic Updates or suggested by using Express option at
Windows Updates. Only the Custom option. Seems real stupid to me, but the
logic MS uses to handle Updates often escapes me. Like making IE7 a
Recommended Update, but then having Automatic Updates install it. Dumb,
dumb, dumb!

PLEASE!! If you're not reasonably adept at using Windows, backing up
Registries, restoring same, etc., DON'T try these Unofficial Updates until
others have proven them out.

--

Gary S. Terhune
MS-MVP Shell/User

Gary S. Terhune wrote:
| Terhune hasn't bothered to test, since others have done the deed
| satisfactorily. I've updated the instruction files.

Let me go see...
http://www.grystmill.com/articles/tz_update.htm
Yes, the Readme.txt is updated...
.......Quote..........
Instructions for installation:
1. Double-click TZ_UP.bat
2. Click OK when asked if you want to merge the Registry data.
3. Click OK when told that Merge was successful.
4. Close the DOS Prompt window if necessary.
5. Double-click the WIndows clock in your System Tray, or
open Time/Date applet from Control Panel.
6. Change the Time Zone listed to any other Time Zone, click Apply.
7. Change the Time Zone to the one now most appropriate to your locale.
(Normally, this will be the same as the one it was set to when you
opened
the applet, but in some cases the Time Zone for your locale will
have changed name.)
.......EOQ............

I might also add it to the bottom of TZ_UP.bat...

ECHO %windir% TZ_BAK.REG is a backup of the old values.
ECHO
ECHO Remember to D-Clk the clock & "Apply", after
ECHO changing the time zone away & back to your own.

| What I need to do is make certain that MS didn't actually change any
| of the actual data in the keys with the latest patch. I will also
| shell out the $50 necessary to make this thing self-executing.

Can't you do that with WinZip? (I never have, but do believe the ability
is there.)

ONE THING: What does this mean...?...
http://support.microsoft.com/?kbid=928388
2007 time zone update for Microsoft Windows operating systems
......Quote........
Important The update that is described in this Microsoft Knowledge Base
article has been replaced by the update that is described in Microsoft
Knowledge Base article 931836.
......EOQ..........

HOWEVER, IF you have exported irradiated, finalized XP keys &
decontaminated them-- I g'g'guess all is well. I mean the values must be
fine, & hopefully they all will apply to Win9x.

| --
|
| Gary S. Terhune
| MS-MVP Shell/User
|
| "PCR" wrote in message
| ...
| John John wrote:
| | PCR wrote:
| | Gary S. Terhune wrote:
| | | I'll update what I've said thus far by saying that I don't know
| | | for sure that those last instructions are necessary to NT/2K
| | | *OR* 9x systems.
| |
| | Neither do I, but, as John John said... If Time/Date Properties
| | were used to advance the date, then clicking OK to that filled
| | the other Registry key...
| |
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation
| |
| | I'm thinking, if DOS was used, then...
| |
| | (a) Something like NisTime could have done it.
| | (b) What was the prior EST date?
| | Whatever... likely it was passed too!
| |
| | I did a fresh, clean install of Windows 98SE to test this and I can
| | confirm that the time changes will NOT happen unless the contents
| | of the
| |
|
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation
| ]
| | are refreshed to reflect the changes made in the
| | [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time
| | Zones] keys.
| |
| | I did regsnaps of the key in question, applied Gary's fix and
| | rebooted. To do the test I rebooted and adjusted the time and
| | date in the BIOS. After rebooting, the time did not change at
| | the new
| | DST ordered date and time without doing additional steps to have
| | Windows update the information in the registry.
|
| OK. I was thinking, even if BIOS was used to advance the date, there
| may have been values in this key (the old values) that STILL would
| be passed & trigger the time change when Windows started. I see
| somehow that did not happen, but I am loath to do the calculations
| why, even if I could remember the old dates. Of course, left to
| their own workings & a normal click of the clock, they would trigger
| things at the wrong date anyhow. SO...
|
| I am well satisfied it IS NECESSARY to get the fit/proper values in
| there. I see Terhune still will test it himself. OK, then.
|
| | To have Windows
| | reload the key I simply clicked on the Toolbar clock "Adjust
| | Date/Time" and just clicked once on the up/down ↑↓ time adjust
| | arrow, just one simple click to get the applet to activate and
| | offer the "Apply" option. Clicking on "Apply" forced Windows to
| | reread and load the correct information in the key. Only after
| | doing this step did the time advance as expected at the right date
| | and time.
|
| OK. That's good to know that any click on "apply" of that requestor
| would cause the whole tab to recalculate & save its data, whether a
| particular box was changed or not. OK, thanks.
|
| | Clicking the "Apply" button in the Date/Time applet caused Windows
| | to update 2 values in the CurrentControlSet key:
| |
| | ----------------------------------
| | Values modified:2
| | ----------------------------------
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| | 00 00 0A 00 00 00 05 00 02 00 00 00 00 00 00 00
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| | 00 00 0B 00 00 00 01 00 02 00 00 00 00 00 00 00
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| | 00 00 04 00 00 00 01 00 02 00 00 00 00 00 00 00
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| | 00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00
| |
| | ----------------------------------
| | Total changes:2
| | ----------------------------------
| |
| |
| | John
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| Should things get worse after this,
| PCR
|

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR

Good idea, but in 2K, the BAT file automatically closes on Exit, so it will
have to be....

ECHO Press any key to Exit.

And I think I'll just add the last three steps to the BAT Echoes, make the
ZIP self-executing, since lots of folks will need to actually change their
time zone... Everyone outside the US that is affected, basically. Like
Mexico.

Have to relearn my DOS!!!

--

Gary S. Terhune
MS-MVP Shell/User

"PCR" wrote in message
...
Gary S. Terhune wrote:
| Terhune hasn't bothered to test, since others have done the deed
| satisfactorily. I've updated the instruction files.

Let me go see...
http://www.grystmill.com/articles/tz_update.htm
Yes, the Readme.txt is updated...
......Quote..........
Instructions for installation:
1. Double-click TZ_UP.bat
2. Click OK when asked if you want to merge the Registry data.
3. Click OK when told that Merge was successful.
4. Close the DOS Prompt window if necessary.
5. Double-click the WIndows clock in your System Tray, or
open Time/Date applet from Control Panel.
6. Change the Time Zone listed to any other Time Zone, click Apply.
7. Change the Time Zone to the one now most appropriate to your locale.
(Normally, this will be the same as the one it was set to when you
opened
the applet, but in some cases the Time Zone for your locale will
have changed name.)
......EOQ............

I might also add it to the bottom of TZ_UP.bat...

ECHO %windir% TZ_BAK.REG is a backup of the old values.
ECHO
ECHO Remember to D-Clk the clock & "Apply", after
ECHO changing the time zone away & back to your own.

| What I need to do is make certain that MS didn't actually change any
| of the actual data in the keys with the latest patch. I will also
| shell out the $50 necessary to make this thing self-executing.

Can't you do that with WinZip? (I never have, but do believe the ability
is there.)

ONE THING: What does this mean...?...
http://support.microsoft.com/?kbid=928388
2007 time zone update for Microsoft Windows operating systems
.....Quote........
Important The update that is described in this Microsoft Knowledge Base
article has been replaced by the update that is described in Microsoft
Knowledge Base article 931836.
.....EOQ..........

HOWEVER, IF you have exported irradiated, finalized XP keys &
decontaminated them-- I g'g'guess all is well. I mean the values must be
fine, & hopefully they all will apply to Win9x.

| --
|
| Gary S. Terhune
| MS-MVP Shell/User
|
| "PCR" wrote in message
| ...
| John John wrote:
| | PCR wrote:
| | Gary S. Terhune wrote:
| | | I'll update what I've said thus far by saying that I don't know
| | | for sure that those last instructions are necessary to NT/2K
| | | *OR* 9x systems.
| |
| | Neither do I, but, as John John said... If Time/Date Properties
| | were used to advance the date, then clicking OK to that filled
| | the other Registry key...
| |
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\TimeZoneInformation
| |
| | I'm thinking, if DOS was used, then...
| |
| | (a) Something like NisTime could have done it.
| | (b) What was the prior EST date?
| | Whatever... likely it was passed too!
| |
| | I did a fresh, clean install of Windows 98SE to test this and I can
| | confirm that the time changes will NOT happen unless the contents
| | of the
| |
|
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation
| ]
| | are refreshed to reflect the changes made in the
| | [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time
| | Zones] keys.
| |
| | I did regsnaps of the key in question, applied Gary's fix and
| | rebooted. To do the test I rebooted and adjusted the time and
| | date in the BIOS. After rebooting, the time did not change at
| | the new
| | DST ordered date and time without doing additional steps to have
| | Windows update the information in the registry.
|
| OK. I was thinking, even if BIOS was used to advance the date, there
| may have been values in this key (the old values) that STILL would
| be passed & trigger the time change when Windows started. I see
| somehow that did not happen, but I am loath to do the calculations
| why, even if I could remember the old dates. Of course, left to
| their own workings & a normal click of the clock, they would trigger
| things at the wrong date anyhow. SO...
|
| I am well satisfied it IS NECESSARY to get the fit/proper values in
| there. I see Terhune still will test it himself. OK, then.
|
| | To have Windows
| | reload the key I simply clicked on the Toolbar clock "Adjust
| | Date/Time" and just clicked once on the up/down ↑↓ time adjust
| | arrow, just one simple click to get the applet to activate and
| | offer the "Apply" option. Clicking on "Apply" forced Windows to
| | reread and load the correct information in the key. Only after
| | doing this step did the time advance as expected at the right date
| | and time.
|
| OK. That's good to know that any click on "apply" of that requestor
| would cause the whole tab to recalculate & save its data, whether a
| particular box was changed or not. OK, thanks.
|
| | Clicking the "Apply" button in the Date/Time applet caused Windows
| | to update 2 values in the CurrentControlSet key:
| |
| | ----------------------------------
| | Values modified:2
| | ----------------------------------
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| | 00 00 0A 00 00 00 05 00 02 00 00 00 00 00 00 00
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\StandardStart:
| | 00 00 0B 00 00 00 01 00 02 00 00 00 00 00 00 00
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| | 00 00 04 00 00 00 01 00 02 00 00 00 00 00 00 00
| |
|
HKLM\System\CurrentControlSet\Control\TimeZoneInfo rmation\DaylightStart:
| | 00 00 03 00 00 00 02 00 02 00 00 00 00 00 00 00
| |
| | ----------------------------------
| | Total changes:2
| | ----------------------------------
| |
| |
| | John
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| Should things get worse after this,
| PCR
|

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR