Hello, Managers. Here is my original question:
> Hello Managers. I have a problem with the timezone. If I run the
> "zdump -v GMT+1" command I get the following:
>
> Under Tru64Unix 4.0F:
>
> ...... gmtoff=3600
>
> Under TruCluster 5.1A, Tru64 Unix 5.1A, 5.1B:
>
> ...... gmtoff=-3600
>
> It seems that under version 5.1x, GMT+1 is the opposite of GMT-1. Tha
> geographic area selected during installation was Europe/Madrid.
>
> Is this an installation problem, or is this the correct operation?
>
> Thanks in advance.
>
> Carlos Rodriguez del Castillo <crodriguez_at_eliop.es>
> ELIOP, S.A.
> Madrid - Spain
and here is a summary of the responses:
martin.moore_at_hp.com: He explained that it is not an installation
problem, but it is the way Tru64UNIX V5.0 and later work. Tru64 UNIX
V5.0 (and later) comply with the POSIX.1 standard (ISO/IEC 9945-1
ANSI/IEEE Std. 1003.1), but earlier versions do not, and this
standard defines GMT+<n> just in the opposite way. So, GMT+1 in
Tru64UNIX V4.0 is equal to GMT-1 in Tru64UNIX V5.0 (and later).
Tom.Peterson_at__delete-this_hp.com: He explained basically how Tru64
UNIX V4.0 and V5.0 work with timezone. I think it is very interesting
so I prefer inserting the complete answer better than summarizing it.
Here is the explanation:
> The 'zonename' argument to the zdump command is a time zone
> specification (by default, assumed to be the name of a time zone
> data file relative to /etc/zoneinfo/). Therefore, the observed
> difference in GMT[+-]* time zone behavior is related to changes to
> certain GMT[+-]* time zone data files under /etc/zoneinfo/. These
> changes are explained below. It's also worth noting that your
> system-wide time zone setting of "Europe/Madrid" does not affect
> the results of zdump for the GMT[+-]* arguments you are using, as
> zdump is using its argument instead of the system default time zone
> setting.
>
> The /etc/zoneinfo/ time zone files and supporting code were updated
> in Tru64 UNIX V5.0 to provide more robust and complete time
> transition
> rules and support for more time zones around the world. Also
> included
> in this update were fixes to certain problems that existed in the
> pre-V5.0 time zone data files and related code.
>
> In particular, there was a fix to the GMT[+-]* time zone data files
> under /etc/zoneinfo/ (and the new /etc/zoneinfo/Etc/ directory) to
> align their functionality with standard POSIX (1003.1) TZ
> environment variable strings of the same name & sign (+/-). That
> is, a standard TZ environment variable setting of, say, "GMT-3"
> used the same GMT offset as /etc/zoneinfo/GMT+3 on pre-V5.0
> systems. This was both confusing to customers and inconsistent
> with the most recent zoneinfo sources available from the
> defacto-standard public domain Olson time zone repository at
> ftp://elsie.nci.nih.gov/pub/, from which our time zone data files
> are derived, and which is used by several other *NIX
> implementations.
>
> In Tru64 UNIX V5.0 and later releases, the GMT[+-]* time zone data
> files are consistent with their POSIX TZ counterparts. They are
> also consistent with TZ behavior on other operating systems, such
> as
> HP-UX.
> That is, when the base time (seconds since the Epoch) is the same
> on both HP-UX and V5.0 (and later) Tru64 UNIX systems, setting TZ
> to,
> say,
> "GMT-3" on either system will use the same GMT offset as it would
> if the /etc/zoneinfo/localtime link on Tru64 UNIX V5.* (and later)
> were set to /etc/zoneinfo/GMT-3 (or /etc/zoneinfo/Etc/GMT-3). The
> same result occurs when setting TZ to ":GMT-3" (note the leading
> ':') on V5.0 (and later) Tru64 UNIX systems. The leading ':' TZ
> format
> causes
> processes in that environment to use the time zone data file
> (relative
> to /etc/zoneinfo/) whose name matches the string following the ':'.
> See the tzset(3) reference page for more details.
>
> Regarding pre-V5.0 Tru64 UNIX systems, it's worth pointing out that
> despite the difference in GMT[+-]* time zone data file
> functionality, those systems DO handle standard POSIX-style
> GMT[+-]* TZ environment variable strings correctly (ie: those with
> no leading ':').
>
> Also note that the argument to the zdump command does not require
> the leading ':', but rather, first assumes that the argument is the
> name
> of
> a time zone data file relative to /etc/zoneinfo/. If it is not,
> only then does zdump interpret the argument as a POSIX-style TZ
> environment variable string.
>
> In summary, the TZ environment variable handling and GMT[+-]* time
> zone
> data file names on Tru64 UNIX V5.0 (and later) are consistent with
> conventions from the standards (POSIX and others). They are also
> consistent with TZ format/handling on other operating systems, such
> as HP-UX. These changes were made in Tru64 UNIX V5.0 in order to
> correct the original dispartity with the standards syntax and to
> function consistently with other systems. The difference in output
> that you
> are
> seeing from zdump with GMT[+-]* arguments is reflective of these
> changes.
>
> As far as workarounds, someone using Tru64 UNIX V4.* could set the
> system-wide /etc/zoneinfo/localtime link to, say,
> /etc/zoneinfo/GMT+3
> to
> match the POSIX-style "GMT-3" setting on Tru64 UNIX V5.0 (and
> later) or other systems. Or, as long as the base times are the
> same, one could also use a TZ environment variable setting of
> ":GMT+3" or "GMT-3" on their Tru64 UNIX V4.* systems, though this
> would only affect the
> current
> environment - not the entire system. For zdump, the solution is
> simply to use the opposite sign for GMT[+-]* arguments between
> Tru64 UNIX
> V4.*
> and V5.* systems.
>
Now I know it is not a problem of my installation, I feel relaxed. It
is not a problem if I have to link to GMT-1 instead of GMT+1 because
is how Tru65Unix V5.0 works.
Thanks to all. The answers have been really useful and interesting.
Best regards,
Carlos Rodriguez del Castillo <crodriguez_at_eliop.es>
ELIOP, S.A.
Madrid - Spain
Received on Fri Jul 11 2003 - 09:55:30 NZST