[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: DST change and home auto...



In article <46112082$1_1@xxxxxxxxxxxxxx>, lgardner@xxxxxxxxxxxxxxxxxxxxxxxxxx (Lewis Gardner) writes:

| I manage several networks running mostly XP pro all syncing to local
| Linux servers running NTP. The problem is that M$ in their wisdom
| allowed machines syncing to a LOCAL time server to calculate DST offsets
| at the machine level. This is madness.

What else could they do?  Are you suggesting that there is some way to
get timezone information from an NTP server (local or otherwise)?

| I used WindowsXP-KB931836-x86-ENU.exe on any machines that had SP2 and
| tzedit.exe on the others to get the clocks right. Unfortunately these
| patches only correct the time not fix the root of the problem since the
| time offset is still calculated on the local machine.

I don't know about the patch, but tzedit fixes the root of the problem
as far as the machine is concerned.  The interesting issue is binaries
that incorporate their own DST rules, most commonly in tzset in the C
library.  At least as far back as 1996 (that's just the source that I
have handy) the MSC Windows library tzset calls GetTimeZoneInformation(),
so anything using that should be ok.  Old DOS binaries are of course a
problem since all (as far as I know) MSC DOS libraries had hard coded
rules in tzset.  I was lucky enough that someone sent me the sources
for the MSC 6.00 DOS libraries so I could fix tzset and recompile all
my programs that depend on it.  It might be interesting to know whether
the hard coded rules ever made it into any older version of the MSC
Windows libraries; that would be something to watch out for.

				Dan Lanciani
				ddl@danlan.*com


comp.home.automation Main Index | comp.home.automation Thread Index | comp.home.automation Home | Archives Home