DST

[Oviwan]

hey folks

We had have some problem with the timezone. We are located in europe but on our rp4440 (11.11) the time changed on the 11 of march and not on the 25 of march. on our rx4640 (11.23) it works fine.

the TZ is set to MEZ-1MESZ on both models and the time is synchronized by ntp.

I'm not sure whether a colleague has changed it after the 11 of march on the rp4440 to MEZ-1MESZ.

Are there other dependent setting for the dst? Can I be sure that it won't happen again in fall?

Thanks in advance

Regards

[Dennis Handly]

Have you set your clock correctly? Right now it is:
$ date -u
Tue Jun 19 10:05:23 UTC 2007

If you don't have this set correct, you can't expect setting TZ to work.

Changes for March 11, were in general for the US only for Y2K7.

[Oviwan]

Hey

my date is:

$date -u
Tue Jun 19 11:46:49 UTC 2007
$date
Tue Jun 19 13:46:49 MESZ 2007

Regards

[James R. Ferguson · Accepted solution]

Hi:

It's quite easy to read the rules for the appropriate stanza in '/usr/lib/tztab' using the manpages for 'tztab(4)' as a guide. You should easily be able to satisfy yourself that your setting are correct or not.

If you patched your 'tztab' before your March transition, but did not reboot or restart long-running processes like the 'cron' daemon and databases, it is possible that the behavior you saw was a consequence of previously cached rules.

Regards!

...JRF...

[Oviwan]

Thanks

We haven't patched tztab. I compared the file on both models and the entries for the MEZ-1MESZ section are exactly the same. hence I proceed from the assumption that it should work in fall...

TZ gets its value from /etc/TIMEZONE right?

[James R. Ferguson]

Hi (again):

> TZ gets its value from /etc/TIMEZONE right?

Yes, by default when '/etc/profile' is sourced during login, but any user or process is free to set and export TZ to any value they choose.

Regards!

...JRF...

[Dennis Handly]

No need to check in the fall, you can use the perl script in this DST thread to check now:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1095131

[Oviwan]

Thanks for the link.
I executed dst.pl on both models but different output:

# model
9000/800/rp4440
# perl dst.pl
Sun Apr 01 01:59:59 MET 2007 --> Sun Apr 01 03:00:00 MESZ 2007
Sun Oct 28 01:59:59 MESZ 2007 --> Sun Oct 28 01:00:00 MET 2007
# echo $TZ
MET-1MESZ

# model
ia64 hp server rx4640
# perl dst.pl
Sun Mar 25 01:59:59 MEZ 2007 --> Sun Mar 25 03:00:00 MESZ 2007
Sun Oct 28 02:59:59 MESZ 2007 --> Sun Oct 28 02:00:00 MEZ 2007
# echo $TZ
MEZ-1MESZ


we have several rx4640 and rp4440 models and on every box it's the same output.

what I have to change that it works?

Regards

[Dennis Handly]

>I executed dst.pl on both models but different output:

You seem to have two different TZ settings:
MET-1MESZ
MEZ-1MESZ

So if TZ is MET-1MESZ, it won't work correctly, since that isn't in tztab.

So /etc/TIMEZONE, or /etc/profile or .profile has the bad value.

[Oviwan]

Thanks a lot. I didn't see it :S

the /etc/TIMEZONE is wrong. can I change its value and then it should work or does it need a reboot?

[Dennis Handly]

>can I change its value and then it should work or does it need a reboot?

You can change the value now. But it will only affect users as they log on. Of course if you have the users manually change TZ, it will work right away.

Of course, if you have an application, it would have to be restarted. And for demons, you would have to reboot.

Note: You probably don't need to reboot until Oct 28, when the zones are again different. Unless you want to know what time is was back in March.

[Oviwan]

Thanks a lot

Set TZ for a user and tested it with dst.pl and it looks good. I will change /etc/TIMEZONE before fall.

Regards

[Dennis Handly]

>I will change /etc/TIMEZONE before fall.

There is no need to wait for that.
But you can reboot later.

[Oviwan]

I know, thanks for helping.