Here's the deal:

When you change the time zone, Windows reads the data from the chosen Time
Zones sub-key in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time Zones,
then writes that data to the one in CurrentControlSet. Mostly, it parses out
the "TZI" hex string into four parts and copies over the STD and DLT keys.

I can write a script that does that -- read what TZ is currently in use in
the CurrentControlSet, suck out the info from the HKLM\Software...Time Zones
sub-key, parse it out and write it back to the CurrentControlSet key. But if
the actual sub-key of HKLM\Software...Time Zones needs to be changed, as it
does for "Central Time (Mexico)" (which used to be plain old "Central Time")
and several others, then that trick doesn't work. Best one can do for
updating a bunch of machines in such a situation is to update one machine,
Export the CurrentControlSet\...\TimeZoneInformation key, then merge it into
all the machines that are in the same TZ, before or after updating the
machines with my patch or similar. So long as nobody messes with the
Date/Time applet, it really doesn't matter if the updates are applied or
not. They're only there to provide info to the applet when changes are made.
In legacy systems, anyway. In WinXP and up, there's much more to it than
that.

--
Gary S. Terhune
MS MVP -- Shell/User
http://grystmill.com/articles/cleanboot.htm
http://grystmill.com/articles/security.htm

"PCR" wrote in message
...
"Gary S. Terhune" wrote in message
...
| *I* am not adding a damned thing, except the MapID values. I
*subtracted* a
| bunch of stuff that's irrelevant to the legacy OSes. *Microsoft* added
the
| new Time Zones. Which is why people in other parts of the world need
to
| verify that they don't need an entirely new TZ setting instead of
using the
| same old one when they do the switcheroo.

So, for them, there might be more to do than to just update...

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion\Time Zones
&
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\TimeZoneInformation

...either for the purpose of the time change or time coordination or
something?

| Look at the damned Registry keys if you need to know more. Or just
look at
| the TZ tab in the Time/Date applet. They[re right there, assuming
you've
| applied the update(so).

I would expect Mexicans need to do nothing. I guess letting their keys
alone handles the time switch as before & coordination too. Why are you
or MS adding more?

| --
|
| Gary S. Terhune
| MS-MVP Shell/User
|
| "PCR" wrote in message
| ...
| Gary S. Terhune wrote:
| | Yes, at least ten totally new zones. For example, Mexico didn't
| | change their laws, so they're on the old DST schedule instead of
| | synched with ours. Thus, they need their own zones.
|
| I don't quite understand. Are you adding additional Mexico zones,
| instead of replacing the old ones? Then, how will Windows know which
to
| use in the Date/Time Properties requestor-- &/or anywhere else
Windows
| must use them?
|
| | And some place in
| | central Asia has segregated itself from Russia and its TZ
schedule.
| | Things like that.
|
| So? These will be new ones where none existed before? That hopefully
| will be OK. But I'm not sure I want a double set like you may be
doing
| with Mexico!
|
| | Those are the ones missing MapID values. Plus a bunch if info
that is
| | useful only to WinXP/2K3 "Dynamic Updates" (accounting for future
| | changes).
|
| I am pleased you have chosen to decontaminate these XP keys, as MGDX
may
| have not.
|
| | If you want to see the new ones, use the MGDX update on a fresh
| | Registry and look for the ones that have "Standard Time" added to
the
| | names and missing MapID value.
|
|
|
| | --
| |
| | Gary S. Terhune
| | MS-MVP Shell/User
| |
| | "PCR" wrote in message
| | ...
| | Gary S. Terhune wrote:
| | | Actually, I've *done* all that,
| |
| | Twice now, right? the second, to incorporate the hopefully final
MS
| | update of those zones?
| |
| | | and deleted a lot of crap that is only
| | | useful to XP machines. Plus adding several MapID's where MS
| | | couldn't be bothered. Gotta wonder which mop-wielding janitor
they
| | | saddled this project with. I mean that quite literally, not in
any
| | | way figuratively!
| |
| | I wonder too. I see you had to fiddle with things after the
export.
| | There's no chance totally new zones were created now, or visa
versa?
| | If so, do you have it covered in your doings?
| |
| | | --
| | |
| | | Gary S. Terhune
| | | MS-MVP Shell/User
| | |
| | | "PCR" wrote in message
| | | ...
| | | "Gary S. Terhune" wrote in message
| | | ...
| | | | Note: http://support.microsoft.com/?kbid=931836 corrects
some
| | | | errors in the previous patches. I've nearly finished the
updates
| | | | to account for this and to add some features, but I won't be
| | | | done until late tonight or tomorrow AM, Pacific time.
| | |
| | | Ah! Good! I hope that's their last update, though. So...
| | |
| | | You will run this update on an XP machine, & then export the
| | | Registry key? That's how you do it, maybe reverting some of
the
| | | Registry values too (such as "Eastern Standard Time" back to
just
| | | "Eastern"? I guess that does it, then. Very good.
| |
| | --
| | 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
|
|
|
|
|