Xref: utzoo comp.databases:9430 comp.software-eng:5278 comp.infosystems:220
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!voder!nsc!amdahl!rtech!ingres!jas
From: jas@ingres.com (Jim Shankland)
Newsgroups: comp.databases,comp.software-eng,comp.infosystems
Subject: Re: Time Zones HELP!
Message-ID: <1991Apr6.182727.16147@ingres.Ingres.COM>
Date: 6 Apr 91 18:27:26 GMT
References: <1991Apr5.103756.18982@news.cs.indiana.edu> <1991Apr5.234855.14441@odin.corp.sgi.com> <1991Apr6.021724.6578@sctc.com>
Reply-To: jas@Ingres.COM (Jim Shankland)
Organization: Angular Systems
Lines: 35

Think of time zone information as a display format for an absolute
time, somewhat analogous to a floating point display format.  The
database itself must store absolute time (in practice, Greenwich Mean
Time), while the client chooses a display format (i.e., timezone)
in which to display that time, probably on a per-session basis.
(Unless you really believe that noon in San Francisco comes before
1 p.m. in New York -- which would be a curious model of time.)

Note that daylight savings time enormously complicates things.  If
I want times displayed in San Francisco local time, it is insufficient
to know that San Francisco is 8 time zones west of Greenwich.  I must
also apply a 1-hour daylight savings time correction *for time values
representing times at which daylight savings time was in effect*.
It is insufficient to be able to correctly display the current time!
Just because daylight savings time is currently in effect does not
mean I should apply the DST correction to a value retrieved from the
database representing some time during last December.  Worse, I need
to take the legislative history of the region into account, so that,
e.g., I can know to apply DST correction to a time in February 1974,
when DST was in effect year-round because of the energy crisis.
I need to distinguish between Arizona time, which is in the Mountain
time zone, but does not "do" DST, and Colorado time, which is in the
Mountain time zone, but *does* have DST.

Accurately representing future times requires complete knowledge of
any DST laws that might be passed in the future.  As far as I know,
no currently available software does this correctly.

Arthur David Olson of NIH (I think) has written a timezone library in
C that does as much of this stuff as possible.  It includes tables
encoding the whims of dozens of state and national legislatures.
You should be able to pick this up from your comp.sources.unix
archives, or FTP it from somewhere.  Ask around.

jas