ATT System V Rlease 3.1 and Timezones

seismo!nbires!vianet!devine seismo!nbires!vianet!devine
Sat Dec 13 06:29:57 UTC 1986


  My, this proposal sounds familiar :-).  I've since been won over
to the stick-the-stuff-in-a-file-and-use-functions party.


> 2.  Init (/etc/init == process 1) reads and parses this file  and
> sets the environment of all children processes with the TZ variable...

  There is no guarentee that some fiend doesn't step on the value
before passing it to someone else.  Even if there are no fiends, there
may be remote users.  One needs a mechanism to find out the correct
timezone information from an unimpeachable source.  "Source'ing"
/etc/timezone is not slick if your process isn't the Bourne/Korn shell.


> 3. The TZ variable has new syntax and fields.  First as sample
> 	TZ=QST-3:15:25QDT-2:25:12;281/02:00:00,315/01:00:00

> Comments:
> The new syntax for TZ allows for any time  zone  rule,  but  only
> allows  ONE  change  per year.  The varialbe must be modified and
> reset for the year being printed.  Thus is TZ is set for  1987  a
> full ctime for a previous year will result in odd information for
> a few days each spring and fall (US).

  This goes to the heart of the proposal.  I tried hard to convince
myself that one year's definition suffices.  However, it is certainly
possible to do multiple years and to hide the nastiness as well by
using a collection of files.  When I proposed a redefinition of TZ
to hold more info, it was in part because I didn't want to break
UNIX conventions.  I guess that is one of the underlying concern in this
proposal too.  Unfortunately they were always broken with respect to
correctly handling the world's variety of timezones.

Bob Devine




More information about the tz mailing list