Xref: news2.mv.net comp.os.msdos.djgpp:4337
From: eggert AT twinsun DOT com (Paul Eggert)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: What is all this "timezone" stuff for?
Date: 28 May 1996 16:51:55 -0700
Organization: Twin Sun Inc, El Segundo, CA, USA
Lines: 50
Message-ID: <4og3ir$k3d@white.twinsun.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 960526085413 DOT 7733E-100000 AT is> <4oehjq$o95 AT hawk DOT le DOT ac DOT uk>
NNTP-Posting-Host: 127.0.0.1
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Clive Page <cgp AT le DOT ac DOT uk> writes:

>This whole discussion has been based on the assumption that an algorithm
>exists that can determine the difference between local time and UTC (GMT
>as was).

You've got it backwards.  The files exist because there is no such algorithm,
and UTC offset calculations perforce refer to tables that record decisions
made by politicians about clocks.

These days, many network applications require knowledge of both UTC
and local time, so there has to be _some_ way for the user to specify
the UTC offset.  The simplest way is to have the user specify a single
number, the UTC offset; but this is a pain because it changes from time
to time.  A not-quite-so-simple way is to have the user specify the
current UTC offset and the DST rules; but this is a tedious and error-prone
process, and many users get it wrong.  Both of the above methods have
the drawback that if the rules change, programs misinterpet old timestamps,
since they interpret the old timestamps according to the new rules.
Using tables avoids all these problems and makes it easier on the user.

> Recently lots of diaries and calendars in the UK had incorrect information
> about the dates on which clocks changed, because our government changed the
> relevant dates after lots of stuff had already been printed.  Not
> surprisingly, lots of Unix and VMS systems which relied on supposed
> predictions of these dates got it wrong,

The public domain Unix tz database was updated for this year's change
to the UK rules in December 1994.  If the Unix suppliers and/or
sysadmins had updated their tz database since 1994, they wouldn't have
had the problem.  Yes, I know, many vendors are slow, and many hosts
are not maintained well, but such maintenance problems occur no matter
which of the above ways that one maintains UTC offset and DST rules.
At least the people who care about their clocks had plenty of notice,
and they could update their rules easily.

>It's not just in Europe that things are a mess - I visited Arizona last year

.... which is why the tz database has an entry `America/Phoenix'.
Arizona is not a problem: Phoenix hasn't changed its rules since 1968.

>My respect for the sagacity of those who invented the Posix series of
>standards

Posix does not require the implementation to use configuration files.
You're allowed to use TZ settings like TZ='GMT0BST,M3.5.0/1,M10.5.0/2',
if you like interpreting hieroglyphics like that, and such settings
don't need configuration files.  I prefer TZ='Europe/London', partly
because I don't have to change the TZ setting every time the rules change,
and partly because TZ='Europe/London' handles old timestamps correctly.