Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!bellcore!ulysses!mhuxr!mhuxt!mhuxv!akgua!gatech!ut-sally!std-unix
From: std-unix@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4238@ut-sally.UUCP>
Date: Fri, 21-Feb-86 14:11:54 EST
Article-I.D.: ut-sally.4238
Posted: Fri Feb 21 14:11:54 1986
Date-Received: Sat, 22-Feb-86 03:29:32 EST
References: <4190@ut-sally.UUCP> <4186@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 55
Approved: jsq@sally.UUCP

From: seismo!kobold!ncr-sd!greg
Date: Thu, 20 Feb 86 19:54:17 pst
Organization: NCR Corporation, Rancho Bernardo

In article <4186@ut-sally> Bob Devine proposes a standard method to hold
the timezone information, which keeps the information in a file in a format
suitable for interpretation by the (Bourne) shell.

In article <4190@ut-sally.UUCP> Guy Harris replies:
>		....
>Too specific.  The standard should not give all the implementation details.
>		....
>Unnecessarily incompatible with System V, which specifies the offset from
>		....
>Not sufficient.  The routines that convert between GMT and local time can be
>		....    
>What puts TZ and DST into the environment of each user?  If it's not done by
>		....
>And what about utilities not run by a logged-in user?  Must they look in
>		....

I agree; the scheme is flawed by all of those problems and more.  I don't
have any skill with words (in the way they are used in specifications), but
I would propose that any scheme adopted by the standards commitee should have
the following requirements:
  -  There should be a way that a system administrator could specify a global
     (system-wide) default that is not process-tree related.  In other words,
     it can't depend upon something in the environment.
  -  There should be a way that this can be overridden so that non-default
     timezones can be supported.  Presumably, this can be done on a process-
     tree basis; i.e., it can be carried in the environment.
  -  It should be possible to handle things like multiple timezone changes
     per year (double daylight savings, like during WWII) and timezone changes
     that are not exactly one hour (didn't Newfoundland once have a daylight
     savings change of 1.5 hours?).

Personally, I think a better scheme is the one presented here a month or so
ago, where the timezone information lives in a directory with one file for
each timezone and with the standard timezone linked to a default name.  A user
could override the default by specifying one of the files in an environment
variable, or roll his own file and specify the full path name.  The file
would contain:
  -  The timezone offset and default name.
  -  The rules for the normal conversion and the name for it.
  -  Exceptional periods, the offset, and the name.
Here I am being too specific myself, but I wanted to point out that Bob Devine
has done us a great service by articulating a mechanism for describing the
normal conversion (the second point above); whether this information is to
be included in the file and processed on the fly or pre-processed by some
program into a binary table that can be evaluated quickly is an implementation
consideration.

-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA

Volume-Number: Volume 5, Number 55