DST change did not happen

[Vishnu77]

On some of my 11.11 servers DST change did not happen.

here are some ouputs...
swlist -l patch |grep tztab
# PHCO_34668 1.0 tztab(4) cumulative patch

# swlist -l fileset -a state |grep -i 34668
# PHCO_34668
PHCO_34668.UX-CORE configured

# cd /usr/lib
# ll tztab
-r--r--r-- 2 bin bin 15802 Mar 23 2006 tztab

Not sure what went wrong. we had to change the time manually. Please advise.

Thanks

Vishnu

[Bill Hassell]

Well, most likely you did not have $TZ set properly for your timezone. But the bad news is that you now have set the system clock to the wrong time. The system clock never changes -- it is running GMT (aka, UTC or Zulu time) and must always be set to GMT. Use the command:

date -u

to se the GMT time on your server. It is probably off by an hour (refer to http://www.time.gov/timezone.cgi?UTC/s/0/java for the current UTC time). If you are running NTP, it will no longer work as the time is more than 10 minutes in error.

Never change the system clock until you verify the value for $TZ is correct for your location. The tztab file defines some (NOT ALL) timezones around the world. Setting TZ correctly will show the correct time. See the numerous previous questions and answers about DST.

[Vishnu77]

Thanks Bill. Here is my value

# echo $TZ
EDT5EST

date -u command shows the time ahead by one hour (on the machine where change did not happen and manually corrected) and the date command matches on both the machines.

Can you please let me know what needs to be done to correct the TZ variable?

Thanks

Vishnu

[James R. Ferguson]

Hi Vishnu:

> Can you please let me know what needs to be done to correct the TZ variable?

There is nothing wrong with your TZ setting. As you noted, the result of 'date -u' shows that your server's clock is one-hour ahead (erroneously).

To correct this, *stop* your databases and other time-sensitve applications (including the 'cron' daemon); then set the *correct* UTC value and either reboot or restart your databases, applications and 'cron'.

Regards!

...JRF...

[Vishnu77]

Thanks Again. I understand that i can set the date with date -u and then that would correct the issue for now. But my 2 questions are

1. why did the time did not jump from 1:59:59 to 3:00:00 am on Mar11th inspite of having the correct patches?

2. if i set the correct date using date -u then will there be no issues in April and november?

I just want to find the root cause why the change did not happen?

Thanks

Vishnu.

[Patrick Wallek]

The clock itself NEVER actually changes. HP-UX always uses UTC/GMT time and then applies your TZ variable setting to that time.

Your TZ setting for the east coast of the USA should actually be EST5EDT.

[James R. Ferguson]

Hi:

> why did the time did not jump from 1:59:59 to 3:00:00 am on Mar11th inspite of having the correct patches?

Patrick is correct, in the Eastern US the correct TZ is EST5EDT, not EDT5EST as you posted and as I first missed :-(

If indeed your TZ=EDT5EST, then I believe that *no* transition would occur since the system "thought" that is was already in EDT.

This underscores the need to (1) have a correct UTC (GMT) setting:

# date -u

...and to make sure that you have a correct TZ value in '/etc/TIMEZONE' for default behavior.

Regards!

...JRF...

[Vishnu77]

OK Cool. Thanks so here is the remedy.Please tell me if this is OK.

stop DB
change the TZ using set_parms and select
EST5EDT.
change the time using date -u and set the correct GMT time
when the machine reboots and comes back the time shown by the date command should match with the correct east coast time (day light saving applied)

is this approach correct? similar to EST5EDT what is the correct PST setting? is it PST8PDT?

Thanks a lot

Best Regards

Vish

[Patrick Wallek]

Everything sounds good.

Yes, you are correct about the US Pacific time zone.

For the continental USA:

EST5EDT
CST6CDT
MST7MDT
PST8PDT