Time zone: the next generation

[Greg Black]

On 2005-03-06, Robert Elz wrote:
>     Date:        Thu, 3 Mar 2005 14:49:27 -0500 
>     From:        "Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov>
>     Message-ID:  <75DDD376F2B6B546B722398AC161106C74038F at nihexchange2.nih.gov>
> 
>   | As long as we're making changes, it's best to do as much as possible
>   | (to avoid the need for further change down the road).
> 
> No, please try and avoid typical 2nd system effects, with the grand
> temptation to add everything that anything can imagine might possibly
> be of some interest to someone, somewhere, sometime.   Change only
> what absolutely needs changing because of demonstrated need now.  What
> exists is currently pretty good, the 64 bit issue is certainly going to
> bite sometime, so that one ought be fixed, there's nothing else (or
> very little) so seriously wrong with that exists now that makes it
> important to change, I suspect.

I support this argument, with a couple of small but important
exceptions (see below).

> Back to 1970, forward to today + 100 years (maybe 200, no more).

No, this is not enough for common uses of today's systems.  We
deal with dates in commerce and academia all the time to get our
work done.  One kind of date that we have to deal with regularly
is birth dates.  Everybody here was probably born before 1970.
And we often have to deal with parents' birth dates.  That means
going back to 1900 at the very least, but probably to 1800 to be
safe.  Equally, we deal with contracts that extend into the
future, not forever, but for periods sometimes in excess of 100
years, so we need to go 200 years forward as well.  With this
small window of 400 years, we avoid most of the hard stuff while
also providing a date thing that is useful to common software,
instead of continuing to force every database vendor in the
world to invent yet another date mechanism.

Greg