[ntp:questions] Re: Problems with the Timezone

Per Hedeland per at hedeland.org
Fri May 12 00:16:26 UTC 2006


In article <T1147382048 at djwhome.demon.co.uk> david at djwhome.demon.co.uk
(David Woolley) writes:
>In article <1147351652.229009.51090 at j73g2000cwa.googlegroups.com>,
>Marvin Garcia <marvingm at gmail.com> wrote:
>
>> But what i dont get is why with a local reference clock i always used
>> GMT-4 in solaris and even in windows has always work fine with GMT-4.
>> But now that we decided to change to a external reference clock the
>> timezone have to change. that's what i dont now why?
>
>Probably because your machine's time was completely broken before but 
>you never noticed, because you never had something with a correct 
>timestamp.  GMT-4 is doubly broken; GMT is only suitable for zero 
>offsets, and because the sign is wrong.

Hm, well, I'd say it was because he never looked at the actual system
time, only the local time displayed by 'date', 'ls', etc. Ignoring the
zone designation, his hours/minutes/seconds were correct - but the
system time, which should be UTC, was actually 8 hours off from UTC.

>Old style Unix time zone codes almost certainly use positive numbers for
>the USA because Bell Labs was in the USA.  On the other hand, the proper
>international standard uses negative numbers for the USA.

I think the proper international standard for the TZ variable is POSIX,
about which the Olsen time zone data files (which are fascinating
reading btw:-) has this to say:

# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich.  For example, TZ='Etc/GMT+4' uses
# the abbreviation "GMT+4" and corresponds to 4 hours behind UTC
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UTC (i.e. east of Greenwich).

This is in the 'etcetera' file, which defines zones that are
sort-of-like the "raw" TZ code:

$ TZ=XXX-4 date
Fri May 12 04:03:37 XXX 2006
$ TZ=Etc/GMT-4 date
Fri May 12 04:03:46 GMT-4 2006

Anyway, the problem isn't really with the sign - after all, giving "the
number of hours you need to add to local time to get UTC" makes just as
much sense as giving "the number of hours you need to add to UTC to get
local time" - but (as you say) with the weird idea of combining the
"GMT" string with the offset, making it "look like" something that
should be added to GMT, and (for the "raw code") giving a bogus zone
designation in 'date' output. I wonder where that comes from...

--Per Hedeland
per at hedeland.org




More information about the questions mailing list