Time Change Patch

[wayne barton_2]

I have installed the patch for the time change in March, and tested it out. Everything went fine. However, I then tested the changing of time back in November, and nothing happened?

During the March change, the time moved forward 1 hour at 2:00am. Great!

But, the change for Nov 11 at 2:00am didn't take place. What am I doing wrong?

Thanks,
-wb

[James R. Ferguson]

Hi Wayne:

The new US rules make March 11, 2007 and November 4, 2007 the transition points. On March 11 the time moves from 01:59:59 to 03:00:00. On November 4 the change is from 01:59:59 to 01:00:00.

Regards!

..JRF...

[A. Clay Stephenson]

Use extreme caution in setting the time backwards on a UNIX box; you can cause all sorts of unexpected problems such as make files not working as expected and database (as well as other application) timestamps being corrupt. The safe way to test it is via the attached Perl script. It doesn't read tztab directly but rather uses the same libc() functions that all UNIX applications and commands such as date use. So if this works, everything will work.

For example,
dst.pl -y 2006 will display the time transitions for the current TZ setting for year 2006. Invoke as "dst.pl -u" for full usage.

[Tim Nelson]

I would be interested in why the November date did not work as well..

A perl script is great but I would be more sure of testing real life by changing the time on the server as for the test.

Wayne, maybe a reboot would help. I.e. set time to 1:40am November 11, then reboot and wait until 2am passes.

[A. Clay Stephenson]

Actually because of the way dst.pl is written, is it just as valid a test as actually changing the system time. Changing a time backwards on a production box is not for the informed faint of heart. What dst.pl does is it determines the epoch seconds that mark the beginning and ending of a given year and then does a binary search within that year looking for the exact transition times as reported by the localtime function when the changes occur and reports them. It does not read tztab but assumes that the underlying functions do -- as all UNIX applications should. It is so flexible that it will even work on Windows boxes -- if Perl is installed.

In any event, the fundamental problem with your test was that by setting the time to 02:00, the time transition has already occurred.

[wayne barton_2]

I also would be more interested in why the change didn't take place. Also, the date I used was November 4th and not 11th, sorry for that typo.

I will check again to ensure that NTPD demon isn't running, and try it again. If that fails, I'll try the reboot, however, supposedly, you shouldn't need to reboot??

Thanks for all the comments.
-wb

[James R. Ferguson]

Hi (agtain) Wayne:

Use the Perl script provided by Clay to test the validity of your transition times. You are missing something.

The patch does not per se require a reboot when applied. However, after the update of the 'tztab' file, long-running processes (notably 'cron' and any databases) should be restarted. A a reboot sometime before the timezone(s)' rule changes will mean that any code using, standard C library system calls, will reread and recache the updated rules.

As for 'xntpd' (NTP) this has no affect on the daylight transition. NTP runs in UTC time --- the number of seconds since January 1, 1970 at midnight --- the "epoch" for Unix systems. The concept of a timezone is simply that the *offset* from UTC changes at two points during a calendar year. For me, in the US Eastern timezone, when the number of epoch seconds is 1_173_596_399 is will be Sun Mar 11 01:59:59 2007. One second later at 1_173_596_400 seconds it will be Sun Mar 11 03:00:00 2007.

Regards!

...JRF...

[Dennis Handly]

Recently there was another thread where someone said it didn't work for java and mentioned Nov 11. Then he said it was a typo and was using Nov 4. We never really had any proof it fails.