How to automate changes to DST Time Zone settings in 11.00?

[Paulo A G Fessel]

Hello, everybody.

DST is approaching in Brazil and, like all the past years, we have a new date for enabling DST and other new date to disabling it. The problem is, I haven't found up to date no way to make this process automatic.

Linux provides zic, a time zone compiler which permits me to configure the time zone configuration in advance, so when time comes the system clock is automagically shifted one hour ahead and back. Solaris provides exactly the same schema, so the same solution I use with Linux I can use with Solaris too.

I've verified and zic is not present in HP-UX (at least not in the version we deploy here, 11.00).

Any ideas?

TIA,
Paulo Fessel

[A. Clay Stephenson]

Actually, HP-UX has a very flexible way of doing this. You simply need to edit /usr/lib/tztab and make any changes you like. If there is no definition for your TZ then you can make one up. Man tztab for details -- it will tell you everything that you need to know.

[Jakes Louw]

Remember to edit /etc/TIMEZONE to make your new definition the default....

[Paulo A G Fessel]

Ok, I looked at tztab man page and I'm not quite sure of the things I did.


I added the following lines to tztab:


BRT3BRST
0 0 19 10 2003 0 BRST2
0 0 15 02 2004 0 BRT3


as our summer time begins October 10, 2003 and ends at February 14, 23h59 - that is, at February 15 0h00 DST is ended.


However, changing the date to October 10, 23h59 there is no change in the time zone shown by date and the clock isn't set to one hour ahead:


[root@berc0004:/usr/lib]# date
Sat Oct 18 23:59:46 BRT 2003
[root@berc0004:/usr/lib]# date
Sun Oct 19 00:00:00 BRT 2003


I've tried using also


BRT3BRST
0 0 19 10 2003 0 UTC-2
0 0 15 02 2004 0 UTC-3


with the same results.


What am I doing wrong?


TIA,
Paulo Fessel

[A. Clay Stephenson]

You aren't quite playing by the rules.

QUOTE (from man tztab)
Either the day of the month or the day of the week or the day of the week field MUST BE A RANGE, the other must be a simple number.
ENDQUOTE

BOTH OF YOURS are SIMPLE NUMBERS. You will have to lie to the tztab and pretend that the day of the month is a range; e.g. 18-19, although the intent is usually to fix the weekday and then let the range express all the possible value for say, the 3rd Sunday in October, 15-21. Make this change (for both transitions) and you should be good to good.

By the way, be careful setting the system date (especially backwards); that operation can have all kinds on unanticipated consequences.

[Paulo A G Fessel]

Unfortunately, still no luck.

Here is the new and improved BRT3BRST zone:

BRT3BRST
0 0 13-19 10 2003 0 BRST2
0 1 10-16 02 2004 0 BRT3

all with the neccesary ranges. However it still does the same way:

[root@berc0004:/usr/lib]# date
Sat Oct 18 23:59:00 BRT 2003
[root@berc0004:/usr/lib]# date
Sun Oct 19 00:00:21 BRT 2003

That is, no time zone change, no time change.

Is it neccesary to reboot?

TIA
Paulo Fessel

BTW: Why are the postings to the forums are SKIPPING all blank lines? This makes the postings tremendously hard to read.

[Patrick Wallek]

The blank line issue is a "feature" of the new-and-improved forums. To get a blank line just put a at the beginning of the line before you hit enter.

On to your timezone issue. Did you set your timezone for the system or for the user you are working as to your customized timezone?

# export TZ=BRT3BRST

[A. Clay Stephenson · Accepted solution]

I just tested this but I made a small change. I simply changed the time change definitions in tztab to occur this month (instead of changing the system date) and all worked perfectly.

You can make changes to tztab and test them
by simply
TZ=BRT3BRST date

That will have the effect of setting TZ just for that one command. Use month and day ranges that have already past (or are just about to) to do your testing before making the real changes. This is much safer than resetting the system time. No reboot will be neded because after all, you could have hundreds of users in many different timezones -- each with unique TZ settings.

[Paulo A G Fessel]

Thanks, Clay, it has really solved the problem.

I don't like many "features" of HP-UX, but on this issue I say hats off to HP-UX developers. The zic approach used in Solaris and most Linux distributions is a little cumbersome yet inclusive.

Thanks for all comments,
Paulo Fessel