🚀 go-pugleaf

>From: pyramid!pyrcorp!ncr-sd!greg
Date: Sat, 1 Feb 86 22:45:20 pst
Subject: Re: TZ and TERM per process
Organization: NCR Corporation, Rancho Bernardo

>>From: floyd!opus!ka@SEISMO.CSS.GOV (Kenneth Almquist)
>Date: Tue, 28 Jan 86 21:46:36 EST
>Organization: Bell Labs, Holmdel, NJ
>
>This article proposes a method of handling time zones which I think
>meets all the requirements that have been mentioned.
>
> [ a scheme where timezone information is kept in a binary table
>   and read in upon demand.  Also includes a clever technique for
>   allowing users to use non-local timezones while permiting system
>   programs to still run in local time. ]
>
>Any problems with this?

An interesting idea; I'd like to see it explored further.  The impact
would not seem to be great, there are minimal changes to existing code,
it allows flexibility in the choice of timezone, and it has a system-wide
default that isn't compiled in.

There's one change I would suggest: the offset for each daylight savings
time should be specified independently; sometimes the clock shift is
not exactly one hour -- there are some areas with double daylight
savings (two hours different), for example.  The name of the zone may
have to be specified, as well.  Perhaps a better way would be to have
some entries that compactly represent the usual case (one hour offset,
standard name) and then have some provision for non-standard offsets
and names.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA

Volume-Number: Volume 5, Number 28