TZ and tztab

[antonio elder prado]

hi,
can someone shed some light on how tztab translates TZ.
i am testing the following:
# date
Fri Jun 15 12:02:20 MDT 2007
# echo $TZ
MST7MDT <== WHAT I HAVE ON TIMEZONE file
# TZ=NNN0MMM date <== testing bogus timezone
Fri Jun 15 19:02:55 MMM 2007 <= question 1
# TZ=NNN date
Fri Jun 15 18:03:03 NNN 2007 <== question 2
# TZ=NNN7 date
Fri Jun 15 11:03:14 NNN 2007
# TZ=MMM date
Fri Jun 15 18:03:31 MMM 2007
# date -u
Fri Jun 15 18:04:13 UTC 2007
#

question1: if you set a timezone NNN0MMM and there is no definition on the tztab about NNN neither MMM, the hpux assumes that whatever is on the right of the offset (in this case 0) to be one hour less than GMT (because of my offset being 0). ?
question2: if there is no offset (for example TZ=NNN) does the OS assumes the offset to be 0?

do you know if pre-DST patching it was possible to have the TIMEZONE=MST (without offset) and MST being defined under tztab as MST7 (7 hs. behind gmt ?).

seems that after the patching it is necessary to have on TIMEZONE=MST7 or CST6 or PST8.

thank you for your help,

./antonio/.

[OldSchool · Accepted solution]

question1: if you set a timezone NNN0MMM and there is no definition on the tztab ...

apparently the "default" condition for dst is a one-hour offset from the std time, and you've specified a 0 offset, so "yes"

question2: if there is no offset (for example TZ=NNN) does the OS assumes the offset to be 0?

Apparently, yes. This would seem to be a reasonable assumtion on the programs part, as the times are calculated using the offset, which in this case is missing.

do you know if pre-DST patching it was possible to have the TIMEZONE=MST (without offset) and MST being defined under tztab as MST7 (7 hs. behind gmt ?).

the patches didn't change the way the program works, and after one of my servers in Arizona, I'd have to say "no". Its been set to MST7 since installation 10 years ag

[Bill Hassell]

The details you need to know about TZ will be found in man environ

tztab is simply a convenient list of popular timezones along with the history and (projected) future time shifts. The environ man page says you can have 3 or more characters for a timezone (like TZ=BIL or TZ=WILLIAM), followed by HH[:MM[:SS]] where HH is hours offset from GMT and :MM is additional minutes, and :SS additional seconds.

So:

TZ=WILLIAM6:33:22 date

will offset the current time display by 5:33:22 from GMT. You can test any value for TZ by setting it on the same line as date -- no need to permanently set the TZ value in your current environment.

> hpux assumes that whatever is on the right of the offset

Actually, HP-UX *never* knows anything except UTC (or GMT or Zulu) time. That is what date -u reports. The standard libraries interpret the GMT time with offset rules found in TZ.

> the OS assumes the offset to be 0?

The library routines default to no offset if none is supplied (which is the same as zero).

> Do you know if pre-DST patching it was possible to have the TIMEZONE=MST (without offset) and MST being defined under tztab as MST7 (7 hs. behind gmt?)

Of course. TZ=MST is the same as TZ=XYA and also TZ=GMT0. MST is *NOT* defined in tztab, rather MST7MDT is aliased to the rules shown in tztab.

> seems that after the patching it is necessary to have on TIMEZONE=MST7 or CST6 or PST8.

Nothing changed in the behavior of the library routines. TZ can be set to any value you want. Only the shortcuts in tztab will have an effect, but just like other flavors of Unix, you can specify a very long TZ value that has all the daylight saving rules, thereby completely bypassing tztab. The man page for environ shows how to specify the rule in your TZ string. You can also create your own custom entry in tztab (man tztab).

[antonio elder prado]

the problem resides not in the tztab or how the OS checks TZ, but in the java (the apps that i use is based on java eng). java has its own tzmapping that disregard the tztab. this db is ascii, so it is just a matter of editing.
thank you all,
./antonio/.