simulated time change failed

[Marc Ahrendt]

my server properly set the "time" back one hour as expected (using TZ=PST8PDT) this past sunday

my question is that why couldn't i simulate this time change on 10/29/04 ...below is what i did and it confused me

date (told me that it was 3pm on 10/29/04)
date 10310159 (moved time up to simulate)
date (told me that it was 1:59am on 10/31/04)
(waited ~2 minutes)
date (told me that it was 2:01am instead of what i expected to be 1:01am!?!)

i know the system counts seconds since 01/01/1970 at 00:00am and that date is depenedt on TZ, but i am not sure why i couldn't simulate the weekend fall back ahead of time

[Steven E. Protter]

Are you running ntp, network time protocol? That could be interfering with your results.

The results of the date command should if accepted without error message be reflected immediatly unless some other factor changes it back.

/var/adm/syslog/syslog.log may have key messages.

SEP

[Marc Ahrendt]

steve, i forgot to mention that i disabled NTP during my testing

also i had no errors in syslog.log and no errors when running the date commands!?!

[Jeff Schussele · Accepted solution]

Hi Marc,

Take a look at the tztab man page & then at the /usr/lib/tztab file.
You'll see that for PST8PDT entry the following line is used
0 1 25-31 10 1975-2038 0 PST8
The key is the last field (#7) it defines what happens - i.e. the shift from deviation from UTC. In your case from 7 to 8 hours difference.
Also note field #2 - that's the hour that the change "starts". This means you should have set the time to 00:59 & then waited to see what the *next* minute after 01:59 displayed. It would have then been 01:00.
Also it may have been prudent to logout & back in to insure you pick up the current TZ value - just to be safe.

HTH,
Jeff

[Bill Hassell]

And to amplify a bit about TZ. There are no errors playing with TZ (like syslog errors). TZ is just a translator code. You don't need to disable NTP since it just keeps UTC (the time that HP-UX keeps) synced. What TZ is doing is providing date (and any other program that calls ctime() and relatives) with a string to process based on the rules for tztab. So you can create your own private timezone, even create your own Daylight Saving switch point (perhaps 13 minutes after midnight...).

In all cases, what happens in your login session affects nothing else on the system. Each user inherits TZ from their profile. Programs that start at bootup get TZ set from /etc/TIMEZONE.

HP-UX can't be bothered with all the politics surrounding timezones (which have nothing to do with astronomical time units) so TZ and tztab were designed to handle almost anything the politicians put together.

[Marc Ahrendt]

thx to all for the info

thx in particular to jeff, the problem/mistake i made was to set the time to 1:59am instead of 0:59am ...even though the clock rolls back to 1:00am after reaching 2:00am the "trigger" is for the system to actually pass 1:00am first as referenced in the tztab file

there was no need to logout and log back in since the TZ value was not being modified at all