[mod.std.unix] POSE proposal for TZ

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/12/86)

>From: seismo!hao!asgb!benish!devine
Date: Tue, 11 Feb 86 11:21:51 mst

  Hi, here is a letter that I sent to the IEEE mailing address for
POSE proposals.  It deals with timezones and Daylight Saving Time
rules and how to incorporate them portably into a UNIX environment.
Its advantages are: follows System III/V model; allows users and
programs to override system timezone information; works for all
present country TZ and DST rules; and flexibility.

Bob Devine; 3133 Lake Park Way; Longmont, CO 80501; (303) 772-2410
(seismo!hao!asgb!devine  sdcrdcf!bmcg!asgb!devine)

---------------------------------------------------------------------
    
    Secretary, IEEE Standards Board
    Institute of Electrical and Electronics Engineers
    345 East 17th Street
    New York, NY 10017
    
    
    
    
      This is a suggested resolution for the handling of world timezones
    and Daylight Saving Time for the P1003/Portable Operating System
    Environment document.  Appendix A.3 asked for such a resolution.
    
    
      The major points of the proposal are:
    
    
            1. There is a world-readable, superuser-modifiable file
               named "/etc/TIMEZONE" that describes the per-system
               timezone information and Daylight Saving Time rules.
    
    
            2. TIMEZONE contains the following lines in Bourne shell
               syntax:
    
               TZ=ABC
               DST="dst1 dst2"
               export TZ DST
    
    
            3. The TZ variable has 2 required parts (and an optional 3rd):
    
               A = standard abbreviation for the timezone as used by the
    	       local area
    	           A :== [A-Z][A-Z]*
               B = plus or minus difference in minutes from Universal Time,
               plus for those locations east of GMT, minus for west
                   B :== [+-][0-9][0-9][0-9]
               C = standard abbreviation for the timezone as used by the
    	       local area when Daylight Saving Time is in effect.  This
	       part of TZ may be absent if DST is not used.
                   C :== [A-Z][A-Z]*
    
               Example for my location in Boulder, Colorado, USA:
                   TZ=MST-420MDT
    
    
            4. The DST variable has 0 or 2 parts in the string.  It has
               zero if no Daylight Saving Time is observed or 2, when DST
               starts and ends, for those places that do observe it.  I
               have been unable to locate any place in the world that has
	       1, 3, or more changes per year to its local time.  If DST
	       is not null, the string means:
    
                 dst1 = a string that describes when DST starts
                 dst2 = a string that describes when DST stops
    
               Both have the syntax of "mmddDhhMM%CCcc".  Translating it:
    
                 mm  = the month (January = 01)
                 dd  = the day of the month (01 to 31)
                 D   = the "search-forward" function number
    	           (0-7) usually 1 or 0
                         0 = use the day mm/dd without translation
                         1 = search forward to the first Sunday
                         2 =        "                    Monday
                         3 =        "                    Tuesday
                         4 =        "                    Wednesday
                         5 =        "                    Thursday
                         6 =        "                    Friday
                         7 =        "                    Saturday
                 hh  = the hour at which the change goes into effect
    	           (00-23) usually 01, 02 or 03
                 MM  = the minute at which the change goes into effect
    		   (00-59) usually 00
                 %   = a '+' or a '-' saying what direction to move
                 CC  = how many hours to move (00-23) usually 01 or 02
                 cc  = how many minutes to move (00-23) usually 00
    
               Example for my location in Boulder, Colorado, USA in 1986:
                   DST="042410200+0100  102510200-0100"
               Alternately, if I already know the exact dates that DST
	       starts and ends for that year, I can use:
                   DST="042700200+0100  102600200-0100"
    
    
            5. If the file is unreadable or missing, the default time
	       zone to use is GMT and the default DST is null.
    

            6. The library call "localtime()" is the only system code
               that need interpret the TZ and DST variables.

    
            7. TZ and DST are put into the environment of each user
               when the user logs in.  A user can change create their
               own TZ and DST values and replace the system maintained
               values in their environment.
    
            8. Those utilities that strip off environment information
               can obtain TZ and DST values by reading "/etc/TIMEZONE".
    
    
    
    Bob Devine
    (303) 530-6635
    Burroughs Distributed Systems Group
    6655 Lookout Road
    Boulder, CO. 80301
    
    UUCP: ihnp4!seismo!hao!asgb!devine OR sdcrdcf!bmcg!asgb!devine

Volume-Number: Volume 5, Number 47

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/12/86)

Date: Wed, 12 Feb 86 04:26:15 EST
>From: Chris Torek <chris@MIMSY.UMD.EDU>

I have tried to stay out of this discussion since I know little of
existing time zone standards and have never needed anything but
the 4BSD system time zone.  However, I would like to ask that the
following suggested rule be amended:

>4. The DST variable has 0 or 2 parts in the string.  It has
>   zero if no Daylight Saving Time is observed or 2, when DST
>   starts and ends, for those places that do observe it.  I
>   have been unable to locate any place in the world that has
>   1, 3, or more changes per year to its local time.

Rest assured that the moment this became a standard and everyone
conformed to it (comments upon the likelyhood of that eventuality
notwithstanding), Murphy would strike and Congress would legistlate
some really crazy DST rules.

I see no good reason for requiring the string to have exactly 0 or
2 parts (efficiency of specific implementations does not count as
a good reason).

(I suspect also that once this were standardised, someone would
come up with a time zone name that requires a digit or a plus or
minus sign, making rule 3 unworkable as well....)

Chris

Volume-Number: Volume 5, Number 48

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/14/86)

Date: Fri, 14 Feb 86 00:51:16 PST
>From: sun!guy@seismo.UUCP (Guy Harris)

>      The major points of the proposal are:
>    
>            1. There is a world-readable, superuser-modifiable file
>               named "/etc/TIMEZONE" that describes the per-system
>               timezone information and Daylight Saving Time rules.

Too specific.  The standard should not give all the implementation details.
Giving this much detail merely constrains an implementation to use the
particular technique specified, even if it isn't the appropriate technique
to use (on a V7 or 4BSD system, for instance, fetching it from the kernel is
more appropriate, since it's already there).

>            3. The TZ variable has 2 required parts (and an optional 3rd):
>    
>               A = standard abbreviation for the timezone as used by the
>    	        local area
>    	            A :== [A-Z][A-Z]*
>               B = plus or minus difference in minutes from Universal Time,
>               plus for those locations east of GMT, minus for west
>                   B :== [+-][0-9][0-9][0-9]
>               C = standard abbreviation for the timezone as used by the
>    	        local area when Daylight Saving Time is in effect.  This
>	        part of TZ may be absent if DST is not used.
>                   C :== [A-Z][A-Z]*

Unnecessarily incompatible with System V, which specifies the offset from
Universal Time in hours.  (It also requires you to multiply an offset in
hours by 60, which is much better done by a computer.)  See below for a
better way of specifying offsets which aren't an integral number of hours.

>            4. The DST variable has 0 or 2 parts in the string.  It has
>               zero if no Daylight Saving Time is observed or 2, when DST
>               starts and ends, for those places that do observe it.

Not sufficient.  The routines that convert between GMT and local time can be
given a time not in the current year; if the time is in a year prior to the
current one, these routines must still be able to convert it, and must
therefore know the rules for all years prior to the current one.  (The
4.2BSD source indicates that the rules for 1970, 1971, and 1972 in Australia
were all rather different; 1970 had no daylight savings time, 1971 had it
from October 31 to the end of the year, 1972 had it from January 1 to
February 27 and October 31 to December 31, and all subsequent years had it
January 1 to March 7 and October 31 to December 31.  In the US, of course,
we had the infamous "nixonflag" for 1974 and 1975....)  For times in the
future, of course, it will have to rely on a projection (if it could handle
times in the future exactly, I'd put it to work on Sun's stock price...).
    
>            7. TZ and DST are put into the environment of each user
>               when the user logs in.
>
>            8. Those utilities that strip off environment information
>               can obtain TZ and DST values by reading "/etc/TIMEZONE".

What puts TZ and DST into the environment of each user?  If it's not done by
"login", then every program which is used as a login shell must do it.  A
LOT of UNIX systems have many users who log in to a specific application,
which may never run the shell.  As such, it should be done by "login", which
makes the Bourne shell syntax unhelpful.

And what about utilities not run by a logged-in user?  Must they look in
"/etc/TIMEZONE"?  If so, do they have to do their own parsing?  There is
already a routine in System V called "tzset()", which sets the global
variables "timezone" and "daylight".  In vanilla S5, it just scans the TZ
environment variable (which means you have to go through contortions to get
that variable set).  In systems which have a source for time zone
information other than TZ, they can scan TZ if present and non-null, and use
that source otherwise.  In your proposal, "tzset()" should scan that file.
However, we have now eliminated the need for any program to look at
"/etc/TIMEZONE" directly - they should let "tzset()" do it for them.

The trouble is that there are several ways of storing the time zone
information, other than in the TZ environment variable.  V7 stored it,
in effect, in "/unix"; you specified it when you built your kernel.  4.2BSD
also stores it there (in "/vmunix", actually); you can specify it when you
build your kernel, but you can also specify it with the "settimeofday"
system call.  A system running on a machine with an EEPROM might store the
time zone there, and either read it out when the machine is booted or make
it readable by user programs.  A "hosted" system (i.e., a system which
provides a P1003-compatible environment on top of an existing operating
system) might be able to get it out of the host operating system.  A table
containing this operation might be mapped into the address space of all
processes in any of a number of ways, depending on the memory model of the
OS and the whims of the OS's designers.

It's inappropriate to commit to something as specific as "/etc/TIMEZONE";
"tzset()" should be specified as fetching the appropriate information and
setting the "timezone", "daylight", and "tzname" external variables (System
V-style) and also arranging, somehow, for the daylight savings time rules to
be set up.

The only copy of the X3J11 C standard draft I can get my hands on right now
is an old one.  It lists "asctime", "ctime", "gmtime", and "localtime" as
being like their UNIX versions, but doesn't list "tzset", "timezone",
"daylight", or "tzname".  Presumably, it considers them to be part of the
operating system (or environment) rather than the C language/library.  (Have
they been added in later drafts?)  If they haven't been added in later
drafts, I propose that P1003 adopt the System V versions, as specified in
the System V Interface Definition, with the following change:

change

	...the external variable "daylight" is non-zero only if the
	standard U.S.A. Daylight Savings Time conversion should be
	applied.  The program compensates for the peculiarities
	of this conversion in 1974 and 1975; if necessary, a table
	for these years can be extended.

	If an environment variable named TZ is present, "asctime" uses the
	contents of the variable to override the default time zone.  The
	value of TZ must be a three-letter time zone name, followed
	by an optional minus sign (for zones east of Greenwich) and
	a series of digits representing the difference between local time
	and Greenwich Mean Time in hours; this is followed by an
	optional three-letter name for a daylight time zone.

to

	...the external variable "daylight" is non-zero only if the
	standard Daylight Savings Time conversion for the current time
	zone, if any, should be applied.  The external variable "tzname"
	contains pointers to the name of the time zone when daylight
	savings time is	not in effect and when it is in effect in its
	first and second members, respectively.

	The default time zone is settable by the system administrator,
	and is usually the time zone that the majority of the system's
	users are in.  "tzset" normally sets the variables "timezone",
	"daylight", and "tzname" to the values for the default time zone.
	If an environment variable named TZ is present, "tzset" sets the
	variables "timezone", "daylight", and "tzname" from the value
	of this environment variable.  The value of TZ must either be
	of the form "GMT+hh[:mm]", or "GMT-hh[:mm]", specifying an
	unnamed time zone "hh" hours and "mm" minutes ahead of or behind
	Universal Time (if "mm" is not present, it is assumed to be
	zero), or a zone name followed by an optional minus sign (for
	zones east of Greenwich) and a specification of the form "hh[:mm]"
	specifying the difference between local time and Universal Time
	in hours and minutes; this is followed by an optional name for the
	time zone when Daylight Savings Time is in effect.  A time zone name
	must not contain any digits and must not contain the characters "+",
	"-", or ":".  If an unnamed zone is specified, Daylight Savings
	time rules are considered not to apply, and the time zone name is
	assumed to be the value of the TZ environment variable.

I include the "GMT+/-hh:mm" specification on the assumption that there are
unnamed time zones; if this is not so, this part may be deleted.  Note that
unlike the System V TZ value, this permits time zone names to be longer or
shorter than 3 characters.  It also permits fractional-hour time zone
offsets; it uses a different syntax than the one described in the "FUTURE
DIRECTIONS" section, because that section doesn't indicate whether the
time zone offset must be four digits (which would mean that EST5EDT would no
longer be valid) or not (which would mean that OLT7ODT would be ambiguous -
is Out to Lunch Time 7 hours away from GMT or 7 minutes?).  The proposed
syntax is an upward-compatible extension of the current syntax, which the
syntax in the "FUTURE DIRECTIONS" section is not.

If TZ is not set, "tzset" will presumably get the Daylight Savings Time
rules from some standard place (where it gets them from is an implementation
detail which does not belong in P1003).  If TZ is set, there should be some
indication of where it gets the DST rules from.  It can either get them from
some "standard" database of rules, or from an environment variable (either
from additional data at the end of TZ, or from DST), or both (i.e., if the
rules aren't specified in an environment variable, it uses the time zone
specified in TZ to look up the rules in the standard database).

Volume-Number: Volume 5, Number 50

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/18/86)

Date: Sun, 16 Feb 86 00:31:47 cst
>From: ihnp4!uiucdcs!ccvaxa!aglew@SEISMO.CSS.GOV (Andy Glew)

Pardon me if I've missed anything in this discussion, but has anyone 
considered the possiblity of double daylight savings time - not just 
two hours offset, but 2 hours in the deep of summer and one hour in
spring and fall (or, one hour's saving in summer, none in fall, and 
an "unsaving" in deepest winter). 

[ I don't recall anyone mentioning that before.  -mod ]

Volume-Number: Volume 5, Number 51

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/19/86)

>From: hao!asgb!devine@seismo.UUCP (Bob Devine)
Date: Mon, 17 Feb 86 18:00:40 mst

>>From: Chris Torek <chris@MIMSY.UMD.EDU>

>>Discussion of (1) why Daylight Saving Time should not be constrained
>>to either 0 or 2 changes per year; and (2) cautioning against a
>>timezone name that may contain numerals, '+', or '-'.  Both points
>>emphasized the possibility of future bizarre changes.


  Yes, I was aware and worried about both problems.  However, in my
search of timezones and DST rules worldwide I was not able to find any
current or past rules that would have violated the assumptions.  Future
rules are unlikely to break the current conventions for fear of confusing
everybody (it's bad enough now).

  Parsing the strings for TZ _COULD_ be done using reserved characters
but that would really break the old usage of the TZ environment variable.
I'm hoping to only bend it.  Likewise, the library call that interprets
the DST strings _COULD_ be written in a generalized fashion to handle any
number of DST changes per year.  However, I don't think such effort is 
required.

Bob Devine
(BTW, Sys V spell doesn't have "timezone" in its dictionary.)

Volume-Number: Volume 5, Number 52

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/20/86)

>From: seismo!umcp-cs!aplvax!osiris!phil (Philip Kos)


> Bob Devine
> (BTW, Sys V spell doesn't have "timezone" in its dictionary.)


Neither does 4.2, at least on our Pyramid.

Phil Kos
The Johns Hopkins Hospital, Baltimore, MD

Volume-Number: Volume 5, Number 53

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/20/86)

Date: Wed, 19 Feb 86 17:58:51 est
From: seismo!cbosgd.ATT.UUCP!mark (Mark Horton)

>  Yes, I was aware and worried about both problems.  However, in my
>search of timezones and DST rules worldwide I was not able to find any
>current or past rules that would have violated the assumptions.  Future
>rules are unlikely to break the current conventions for fear of confusing
>everybody (it's bad enough now).

You haven't looked hard enough.  Also, the minute you make an assumption,
some congressman or some MP in Britain or Japan or wherever will violate it.

>>>Discussion of (1) why Daylight Saving Time should not be constrained
>>>to either 0 or 2 changes per year;

There is a thing called "Double Daylight Time" which does exactly that.
I think it happened a few years back in some other country (Canada?)
Surely someone on this list can provide details.

>>>and (2) cautioning against a
>>>timezone name that may contain numerals, '+', or '-'.  Both points
>>>emphasized the possibility of future bizarre changes.

On the contrary, the notion of giving a time zone a name is an American
notion.  They also have names in Europe and Australia, but my impression
is that in many parts of the world, such as Japan, time zones are named
according to the ISO format +HHMM, e.g. Japan is +0900.

I'm afraid the variable TZ is already pretty badly broken - it can't be
used in Newfoundland or Central Australia or Saudi Arabia.  (We do have
sites on Usenet in Newfoundland - as far as I know, they all run 4BSD.)

elsie!ado has written some code with a much more flexible structure
(and some additional complexity, which I think is unavoidable.)  I
understand he's going to submit it to this group shortly.  I think
it merits serious consideration.  How much goes into the standard and
how much is left to the implementor isn't clear (e.g. is the format
of the time zone description file part of the standard?) but the code
is intended to be public domain, and it ought to make a good start.

	Mark

Volume-Number: Volume 5, Number 54

std-unix@ut-sally.UUCP (02/21/86)

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

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/23/86)

From: seismo!elsie!ado
Date: Fri, 21 Feb 86 22:48:58 EST

# To unundle, sh this file
echo README 1>&2
cat >README <<'End of README'
@(#)README	1.4

The shell archive of which this file is a part contains man pages for functions
and a file format designed to deal with Daylight Savings Time variations.

The basic idea is to have a system-wide directory that contains binary files
describing time zone rules; functions such as "localtime" could read such
files before doing time conversions.

A manual page for a "time zone compiler" that turns text-file descriptions of
time zone rules into binary files is also included, as is a sample input file
for the compiler.  These would, of course, not be part of the standard;
they are included here only to show that the binary files that would be used
under this scheme can be readily created.

Source code for these functions and for the time zone compiler are available
from seismo!elsie!ado, the person to whom to direct comments (with, perhaps,
carbon copes to cbosgd!mark and seismo!philabs!linus!encore!necis!geo,
who are responsible for any good ideas that show up here).
End of README
echo settz.3 1>&2
cat >settz.3 <<'End of settz.3'
.TH SETTZ 3 
.SH NAME
settz, newctime, newlocaltime \-  convert date and time to ASCII
.SH SYNOPSIS
.nf
.B settz(zonename)
.B char *zonename;
.PP
.B char *newctime(clock)
.B long *clock;
.PP
.B
#include "time.h"
.PP
.B struct tm *newlocaltime(clock)
.B long *clock;
.PP
.B char *tz_abbr;
.SH DESCRIPTION
.I Settz
sets time zone information used by
.I newctime
and
.IR newlocaltime .
If
.I zonename
begins with a slash,
it is used as the absolute pathname of the
.IR tzfile (5)-format
file from which to read the time zone information;
if
.I zonename
begins with some other character,
it is used as a pathname relative to the standard time zone information
directory.  A call of the form
.ti +.5i
.B
settz("")
.br
causes built-in information about GMT to be used; a call of the form
.ti +.5i
.B
settz((char *) 0)
.br
is treated as if it were a call of the form
.ti +.5i
.B
settz("localtime")
.PP
.I Newlocaltime
has the same argument and return value as
.IR localtime .
If
.I newlocaltime
is called before
.I settz
is called,
.I newlocaltime
calls
.I settz
with the value returned by
.B
getenv("TZ").
.I Newlocaltime
sets
tz_abbr
to a pointer to an 
ASCII string that's the time zone abbreviation to be used with
.IR newlocaltime 's
return value.
.PP
.I Newctime
returns a pointer to a string of the form
.ti +.5i
Sat Feb 15 15:45:51 1986 EST\\n\\0
.br
where the last (variable-width) field is the time zone abbreviation.
.SH DIAGNOSTICS
.I Settz
returns zero if all seems well; it returns negative one otherwise
(and sets things up so that its built-in information about GMT is used).
.SH FILES
/etc/tzdir	standard time zone information directory
.SH "SEE ALSO"
ctime(3), getenv(3), tzfile(5)
.. @(#)settz.3	1.3
End of settz.3
echo tzfile.5 1>&2
cat >tzfile.5 <<'End of tzfile.5'
.TH TZFILE 5
.SH NAME
tzfile \- time zone information
.SH SYNOPSIS
.B
#include "tzfile.h"
.SH DESCRIPTION
The time zone information files used by
.IR settz (3)
and
.IR newlocaltime (3)
have the format of the
.I tzinfo
structure described in the include file
.B 
"tzfile.h":
.sp
.nf
.in +.5i
struct tzinfo {
	int	tz_timecnt;
	long	tz_times[TZ_MAX_TIMES];
	char	tz_types[TZ_MAX_TIMES];
	struct dsinfo {
		long	ds_gmtoff;
		char	ds_abbr[TZ_ABBR_LEN+1];
		char	ds_isdst;
	}	tz_dsinfo[TZ_MAX_TYPES];
};
.fi
.PP
The
.B tz_timecnt
field tells how many of the
.B tz_times
and
.B tz_types
stored in the file are meaningful.
Each of the meaningful
.B tz_times
entries is a starting time (as returned by
.IR time (2));
the same-indexed
.B tz_types
entry is the index of the
.B tz_dsinfo
array element that tells about how "local time" is generated starting at that
time.
For a file to be used by
.IR settz ,
its
.B tz_times
entries must be sorted in ascending order.
.PP
In the
.B tz_dsinfo
structures,
.B ds_gmtoff
gives the number of seconds that should be added to GMT;
.B ds_abbr
is the ASCII-NUL-terminated string used as the time zone abbreviation;
and
.B
ds_isdst
tells whether
.B
tm_isdst
should be set by
.IR newlocaltime (3).
.PP
.I Newlocaltime
uses the first element of
.B tz_dsinfo
if either
.B tz_timecnt
is zero or
.IR newlocaltime 's
argument is less than
.BR tz_times[0] .
.SH SEE ALSO
settz(3)
.. @(#)tzfile.5	1.4
End of tzfile.5
echo tzcomp.8 1>&2
cat >tzcomp.8 <<'End of tzcomp.8'
.TH TZCOMP 8
.SH NAME
tzcomp \- time zone compiler
.SH SYNOPSIS
.B tzcomp
[
.B \-d
directory ] filename ...
.SH DESCRIPTION
.I Tzcomp
reads text from the file(s) named on the command line
and creates the time zone information files specified in this input.
If a
.I filename
is
.BR ` - ',
the standard input is read.
.PP
This option is available:
.TP
.B \-d directory
Create time zone information files in the named directory rather than
in the standard directory named below.
.PP
A sharp characters (#) in the input introduces a comment which extends to
the end of the line the sharp character appears on.
Any line which is blank (after comment stripping) is ignored.
Non-blank lines are expected to be of one of three
types:  rule lines, zone lines, and link lines.
.PP
A rule line has the form
.nf
.B
.ti +.5i
.ta \w'Rule 'u +\w'MostNA 'u +\w'FROM 'u +\w'1973 'u +\w'TYPE 'u +\w'Apr 'u +\w'lastSun 'u +\w'2:00 'u +\w'SAVE 'u
.sp
Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
.sp
For example:
.ti +.5i
.sp
Rule	MostNA	1969	1973	-	Apr	lastSun	2:00	1:00	D
.sp
.fi
The fields that make up a rule line are:
.TP
.B NAME
Gives the (arbitrary) name of the set of rules this rule is part of.
.TP
.B FROM
Gives the first year in which the rule applies.
.TP
.B TO
Gives the last year in which the rule applies.
The word
.RB ` only '
may be used to repeat the value of the
.B
FROM
field.
.TP
.B TYPE
Gives the type of year in which the year applies.  If
.B TYPE
is
.B
"-"
then the rule is taken to apply in all years between
.B FROM
and
.B TO
inclusive.
If
.B TYPE
is something else, then the command
.B
.ti +.5i
years from to type
.br
is executed with arguments
.IR from ,
.IR to ,
and
.IR type
taken from the rule line; the rule is taken to apply only in those years
printed by the
.I years
command.

The distributed
.I years
command is a shell script that can handle year types
.B uspres
(United States presidential election years)
and
.B nonpres
(all other years);
other year types may be added by changing the script.
.TP
.B IN
Names the month in which the rule takes effect.  Month names may be
abbreviated.
.TP
.B ON
Gives the day on which the rule takes effect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'lastSun  'u
5	the fifth of the month
lastSun	the last Sunday in the month
lastMon	the last Monday in the month
Sun>=8	first Sunday on or after the eighth
Sun<=25	last Sunday on or before the 25th
.fi
.in -.5i
.sp
Names of days of the week may be abbreviated or spelled out in full.
Note that there must be no spaces within the
.B ON
field 
(or within any other field).
.TP
.B AT
Gives the time of day at which the rule takes affect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'1:28:13  'u
2	time in hours
2:00	time in hours and minutes
15:00	24-hour format time (for times after noon)
1:28:14	time in hours, minutes, and seconds
.fi
.in -.5i
.sp
.TP
.B SAVE
Gives the amount of time to be added to local standard time when the rule is in
effect.  This field has the same format as the
.B AT
field.
.TP
.B LETTER/S
Gives the "variable part" (for example, the 'S' or 'D' in "EST" or "EDT")
of time zone abbreviations to be used when this rule is in effect.
If this field is
.B
"-",
the variable part is null.
.PP
A zone line has the form
.sp
.nf
.ti +.5i
.ta \w'Zone 'u +\w'Eastern 'u +\w'GMTOFF 'u +\w'MostNA 'u
Zone	NAME	GMTOFF	RULES	FORMAT
.sp
For example:
.sp
.ti +.5i
Zone	Eastern	-5:00	MostNA	E%sT
.sp
.fi
The fields that make up a zone line are:
.TP
.B NAME
The name of the time zone.
This is the name used in creating the time zone information file for the zone.
.TP
.B GMTOFF
The amount of time to add to GMT to get standard time in this zone.
This field has the same format as the
.B AT
and
.B SAVE
fields of rule lines;
begin the field with a minus sign if time must be subtracted from GMT.
.TP
.B RULES
The name of the rule(s) that apply in the time zone.
If this field contains
.B
"-"
then standard time always applies in the time zone.
.TP
.B FORMAT
The format for time zone abbreviations in this time zone.
The pairs of characters
.B
"%s"
is used to show where the "variable part" of the time zone abbreviation goes.
.PP
A link line has the form
.sp
.nf
.ti +.5i
.ta \w'Link 'u +\w'LINK-FROM 'u
Link	LINK-FROM	LINK-TO
.sp
For example:
.sp
.ti +.5i
Link	Eastern		EST5EDT
.sp
.fi
The
.B LINK-FROM
field should appear as the
.B NAME
field in some zone line;
the
.B LINK-TO
field is used as an alternate name for that zone.
.PP
Lines may appear in any order in the input.
.SH EXAMPLE
[Since a sample time zone file appears in the shell archive,
this section has been omitted.]
.SH FILES
/etc/tzdir	standard directory used for created files
.SH "SEE ALSO"
settz(3), tzfile(5)
.. @(#)tzcomp.8	1.4
End of tzcomp.8
echo tzinfo 1>&2
cat >tzinfo <<'End of tzinfo'
# @(#)tzinfo	1.5

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	MostNA	1969	1973	-	Apr	lastSun	2:00	1:00	D
Rule	MostNA	1969	1973	-	Oct	lastSun	2:00	0	S
Rule	MostNA	1974	only	-	Jan	6	2:00	1:00	D
Rule	MostNA	1974	only	-	Nov	24	2:00	0	S
Rule	MostNA	1975	only	-	Feb	23	2:00	1:00	D
Rule	MostNA	1975	only	-	Oct	26	2:00	0	S
Rule	MostNA	1976	2037	-	Apr	lastSun	2:00	1:00	D
Rule	MostNA	1976	2037	-	Oct	lastSun	2:00	0	S

# Almost surely wrong:

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	Oz-Eur	1969	1973	-	Apr	lastSun	2:00	1:00	S
Rule	Oz-Eur	1969	1973	-	Oct	lastSun	2:00	0	-
Rule	Oz-Eur	1974	only	-	Jan	6	2:00	1:00	S
Rule	Oz-Eur	1974	only	-	Nov	24	2:00	0	-
Rule	Oz-Eur	1975	only	-	Feb	23	2:00	1:00	S
Rule	Oz-Eur	1975	only	-	Oct	26	2:00	0	-
Rule	Oz-Eur	1976	2037	-	Apr	lastSun	2:00	1:00	S
Rule	Oz-Eur	1976	2037	-	Oct	lastSun	2:00	0	-

# New names

# Zone	NAME		GMTOFF	RULES	FORMAT
Zone	Atlantic	-4:00	MostNA	A%sT
Zone	Eastern		-5:00	MostNA	E%sT
Zone	Central		-6:00	MostNA	C%sT
Zone	Mountain	-7:00	MostNA	M%sT
Zone	Pacific		-8:00	MostNA	P%sT
Zone	Yukon		-9:00	MostNA	Y%sT
Zone	Hawaiian	-10:00	MostNA	H%sT
Zone	Newfoundland	-3:30	-	NST
Zone	Japan		9:00	-	JST
Zone	WET		0	Oz-Eur	WE%sT
Zone	MET		1 	Oz-Eur	ME%sT
Zone	EET		2	Oz-Eur	EE%sT
Zone	AEST		10:00	Oz-Eur	AES%sT
Zone	ACST		9:30	Oz-Eur	ACS%sT
Zone	AWST		8:00	-	AWST	# No Daylight Saving here?

#
# A settz("") uses the code's built-in GMT without going to disk to get
# the information.  Still, we want things to work if somebody does a
# settz("GMT"), so. . .
#

Zone	GMT		0	-	GMT

# Old names

# Link	LINK-FROM	LINK-TO
Link	Eastern		EST5EDT
Link	Central		CST6CDT
Link	Mountain	MST7MDT
Link	Pacific		PST8PDT

# "Pacific Presidential Election Time" is being contemplated in Congress

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	Twilite	1969	1973	-	Apr	lastSun	2:00	1:00	D
Rule	Twilite	1969	1973	-	Oct	lastSun	2:00	0	S
Rule	Twilite	1974	only	-	Jan	6	2:00	1:00	D
Rule	Twilite	1974	only	-	Nov	24	2:00	0	S
Rule	Twilite	1975	only	-	Feb	23	2:00	1:00	D
Rule	Twilite	1975	only	-	Oct	26	2:00	0	S
Rule	Twilite	1976	2037	-	Apr	lastSun	2:00	1:00	D
Rule	Twilite	1976	1987	-	Oct	lastSun	2:00	0	S
Rule	Twilite	1988	2037	uspres	Oct	lastSun	2:00	1:00	PE
Rule	Twilite	1988	2037	uspres	Nov	Sun>=7	2:00	0	S
Rule	Twilite	1988	2037	nonpres	Oct	lastSun	2:00	0	S

# Zone	NAME		GMTOFF	RULES	FORMAT
Zone	New-Pacific	-8:00	Twilite	P%sT

# Next really belongs in a separate file

Link	Eastern		localtime
End of tzinfo
exit
--
	UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie!ado@seismo.ARPA
	DEC, VAX and Elsie are Digital Equipment and Borden trademarks

Volume-Number: Volume 5, Number 57

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/23/86)

Date: Sat, 22 Feb 86 21:14:28 cst
From: ihnp4!uiucdcs!ccvaxa!aglew@SEISMO.CSS.GOV (Andy Glew)

I do not know if double daylight savings has ever been used, 
but I heard a man from Canada's NRC talking about it on CBC radio last year.
The NRC is hoping that the US will go to DST earlier and stay later,
and from that it is only a short step to double time.
This makes better sense the closer you get to the pole.
I do know that several industries in Britain in WWII went to effective
double daylight savings time, by having people report to work earlier
in deepest summer (which is what we should do anyway).

What's all the fuss about, anyway? All times should be recorded in GMT,
since it's the closest thing we have to a standard clock.
Timezone information should only be used for local printing of the time
- dates, ls, etc. For this, the environment variable would be useful.

[ Several people have described what the problems are at length.
Since it's been a while, naturally there are people just starting
to follow the discussion who missed its beginning.  Perhaps I should
repost one of the explanatory articles.  So, a small poll:  If you've
come in late and want to know what all the fuss is about, send me
a note.  If you've been following the discussion all along and remember
a particular specification of the problem which was most clear to you,
let me know.  If I get enough of the former I will repost an
explanatory article, possibly chosen according to the latter.  -mod ]

Timestamps MUST be recorded in GMT, for projects that exchange code across
timezones.

[ The UNIX kernel has always kept internal time in GMT, as have most
other operating systems (VMS seems to be an exception).  There are,
however, programs which write text timestamps in local time.  -mod ]

It is conceivable that knowing what time of his local day the author last
modified his code might be useful, but instead of carrying a timezone
indication, why not carry a true location around, like latitude/longitude,
and look that up in a database (although it might get hairy for spaceships
travelling near c :-).

[ Timezones change per latitude and longitude. -mod ]

Even hairier idea:  have we considered non-24 hour days? Someday, someone is
going to have computers on the moon; they may still be running UNIX (and
Fortran, and Cobol) at that time, and there's no guarantee that they'll
stick to a 24 hour day. There've been a lot of studies that show that men
in isolation go to a 28-30 hour cycle, and without the sun rising to keep
you in synch, there's no reason not to change the definition of "day".
GMT will probably still be kept, but local time takes on a whole new meaning.
Maybe just leave an escape in any timezone environment variable for
local time conversions that don't simply consist of adding an offset?

[ Doubtless it will happen, but probably not within the effective
life of the current P1003 proposed standard.  I suggest the new
INFO-FUTURES list for such discussions.  I will repost the announcement
from UNIX-WIZARDS for it as the next article.  -mod ]

Andy "Krazy" Glew. Gould CSD-Urbana. 
UUCP: ...!ihnp4!uiucdcs!ccvaxa!aglew
ARPA Internet: aglew@gswd-vms.ARPA

[ PS:  Other than interpolating comments, there are exactly two things
which I can't resist doing to submitted articles before posting them
and without asking their authors first:  fixing obviously incorrect
spelling; and fixing incorrect network addresses, like UUCP addresses
given as being for USENET or old-style ARPANET addresses which won't
work anywhere in the ARPA Internet where domain nameservers are in use.
-mod ]

Volume-Number: Volume 5, Number 58

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/26/86)

From: Jack Jansen <seismo!mcvax!jack>
Date: 25 Feb 86 20:56:12 N (Tue)
Organization: AMOEBA project, CWI, Amsterdam

Well, even though the discussion doesn't seem to have anything
to do with standardising, it *is* interesting.

[ Comments on how to handle timezones are explicitly requested
in an appendix of the current P1003 draft.  -mod ]

I like the outside of elsie!ado's proposal, but I think the
implementation could be done more simple and cheap.

First (not too important), if you go for binary files, you
shouldn't put two arrays of fixed size in the beginning.
This will inevitably mean trouble for future generation. If you
*do* insist on binary data, make it variable sized array, and
put a count in.

Second, and most important, I think the method is far too complex
for its achievements. I think something along the following
lines would work as easy, and be much simpler to set up:
- view normal time and dst as *different* timezones. If a certain
  area has had more than one dst offset since written history(jan70),
  see those as different too. Note that different timezones could
  have the same name.
- Per timezone, keep a list with transition-times, and new timezones.
- Further, use a scheme along the lines of elsie!ado's proposal, so
  use files in a specified directory, and use a link to get the
  local default time.
Now, two typical files would look like:
/etc/tz/FOT:
    # FOT - Far Out Time.
    FOT	+11:28		# Offset from GMT
    Apr 1, 1970	FST
    Apr 1, 1971	FST
    Apr 1, 1972	FST.1972
    ...
/etc/tz/FST:
    # FST - Far out Summer Time.
    # Differs by 1:10 hour from FST.
    FST	+12:38
    Sep 1, 1970	FOT
    ...
/etc/tz/FST.1972:
    # FST.2 - Far out Summer Time exceptional situation for 1972.
    # Differs 1:11 hour from FOT.
    FST	+12:39
    Sep 1, 1972	FOT
Note that these files should be in binary, of course, and transition
times in order of ascending magnitude.
Also, if you do a settz("FST"), and present a date in november,
a quick binary search will immedeately get you to the Sep 1 transition,
and get you to the right timezone. Note that this will *also* work for
timezones with the same names: the name in col. 2 of the files, and in
the settz() call, are filenames, and the first entry in the file is
the name that will be used on output.

--
	Jack Jansen, jack@mcvax.UUCP
	The shell is my oyster.

Volume-Number: Volume 5, Number 61

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/26/86)

From: seismo!hao!asgb!devine (Bob Devine)
Date: Tue, 25 Feb 86 19:58:51 mst

  First of all, sorry for the length of this article.  I've been
doing job search type of things the last week.

  It appears that this will be my last posting from this site.
The Burroughs Distributed Systems Group was severely cut for budget
reasons.  The uucp site "asgb" (it stood for Advanced Systems Group,
Boulder) will soon be no more.  In fact, there are only a few
terminals left attached to any VAX.  Our site officially closed
a week and a half ago.

  There has been many responses to my proposal for the handling
of timezones and Daylight Saving Time rules.  Let me respond to
them according to subject.  However, let me first reiterate the
important ideas presented in my proposal of a month ago:

	1. a single timezone definition exists for that system;
	   this definition is the default

	2. timezone and DST rules are kept and passed as
	   environment variables
	
	3. a user (or program) can override the default definition

  The above can be considered a "cleaned-up" way of handling timezone
compared to AT&T System III and V.  DST handling is just an analogous
extension to this.  I proposed this method to deal with the coming
UNIX usage throughout the world.  Specifically, the product line we
were developing used UNIX and was to be offered everywhere Burroughs
does business.  

  My proposal's biggest (and intended) limitation is its inability to
deal with past years at all.  To do that requires a table of such
changes as elsie!ado's proposes.  However, after I started collecting
such rules and saw that they numbered in the thousands I decided for
the simpler proposal.  If anyone wants to, they can see my collection
gathered from a person from the DOT, someone at the National Bureau of
Standards, and several publications from the American Federation of
Astrologers.  However, any collection becomes old quickly.  For example,
China just this month started using 4 timezones instead of the one
centered on Bejing.

  On to the criticisms and questions:

1. Format of proposed DST variable.  Are 0 or 2 changes per year
   sufficient? (Chris Torek, Mark Horton and Andy Glew)
   I believe so for all places __currently__.  The only places that
   I have found to use Double Summer Time are:
       Argentina     1924 and 1969
       Azores        1942 (unclear)
       France        some areas 1940-42
		     everywhere 1943-46 and 1976-77
       Great Britain 1941-47
       Portugal      1942
       Spain         1942-1946
       Tunisia       194x (unclear)

   If Double Summer Time is in modern use, four changes can be put
   into the DST variable.  Re-reading my response to Chris Torek,
   I see that I was unclear.  I wrote that no rules would "violate the
   assumptions" made for the DST variable.  What was not clear was
   the assumption that 4 changes could be used.

2. Numerals, '-', or '+' in timezone names. (Chris Torek and Mark Horton)
   I don't know.  Does anyone have a list of legal timezone names
   and abbreviations (if any) as used by each country?  I have English
   equivalents for some.  The TZ variable can be modified to use
   field separator characters between the names and offset from UT.
   A note: the sign used for the offset should match ISO standards,
   which is the opposite of System V conventions.  Sorry, I don't have
   the ISO document number than details this; it's in a box somewhere.

3. "/etc/TIMEZONE" is too specific.  Use functions. (Guy Harris)
   For the purpose of P1003, Guy is right.  To avoid the confusion
   of all new CTIME(3C) functions, the existing functions should be
   kept though with modifications.  A problem lurks in the use of
   the ctime() function where programs copy the returned string into
   a too short array.

4. Proposed TZ format is too unlike Sys V's. (Guy Harris)

   System V's use of difference is hours is just plain wrong for
   many places (eg., Dominican Republic, Iran, and Saudi Arabia
   where local custom dictates midnight is when the sun sets).
   I proposed using just minutes.  Guy proposes the form "[+/-]H[:m]"
   where "H" is hours and "m" is minutes.  It's a matter of choice.
   It may be preferable to use seconds to be on the safe side.


5. Who puts TZ and DST into a user's environment? (Guy Harris)

   The easy answer is "whatever puts TZ there now".  It is an OS
   specific mechanism.  "login" could do it or a user's login shell
   upon starting up could do it.  I didn't specify in the proposal.


6. What about utilities not run by a logged-in user? (Guy Harris)

   Such utilities should only have to use a library call to obtain
   the timezone name (if desired) and the local time.


7. Use files to hold information about that timezone.
   (steinmetz!davidsen and ncr-sd!greg (Greg Noel))

   Using a file with the name of a timezone won't work for Daylight
   Saving Time rules because one timezone may span multiple countries
   with its named unchanged (eg., Canada and USA) yet the countries may
   have different rules for daylight saving time.  Furthermore, within
   one country, not all areas within a timezone use DST the same way
   (eg., Indiana, Arizona).  A two dimensional grid of timezones and
   countries might be possible but this would probably get unwieldy quickly.
   For users of network file systems and diskless workstations: beware,
   proximity does not imply same rules (for a bad dream, think of a network
   that spans a timezone where there is only one file server and the rest
   of the nodes are diskless -- this contrived example is hard to solve
   with any proposal).
   The second point is that the name of the timezone has to be known
   somehow -- both the default timezone and, if the user selects one,
   the non-system name.  This brings to mind an easy solution of
   environment variables.


  Let me close with the requirements, as I see them, for the handling of
timezone and DST information.  It might be better to debate these instead
of any specific proposals.

1. every site must have default information on its timezone and for DST rules
2. information about the past, while it may be needed in some situations,
   is not essential
3. information about other timezones and areas, while it may be needed
   in some situations, is not essential
4. a user (or program) should be allowed to change the timezone and DST
   information for their use only
5. because the local time conversion is used often, it should be fast
6. changes to the system-default information should be easy to make

So long,
Bob Devine
(home phone: 303/772-2410)

Volume-Number: Volume 5, Number 62

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/28/86)

Date: Thu, 27 Feb 86 15:11:34 PST
From: seismo!sun!guy (Guy Harris)

>   My proposal's biggest (and intended) limitation is its inability to
> deal with past years at all.

You *intended* to make "ctime" only work on times in the current year?  This
is extremely undesirable.  Every UNIX out there can deal with this now, and
people have probably written code that depends on being able to do so.  That
code won't work on a system which doesn't support this.

> 4. Proposed TZ format is too unlike Sys V's. (Guy Harris)
> 
>    System V's use of difference is hours is just plain wrong for
>    many places (eg., Dominican Republic, Iran, and Saudi Arabia
>    where local custom dictates midnight is when the sun sets).
>    I proposed using just minutes.  Guy proposes the form "[+/-]H[:m]"
>    where "H" is hours and "m" is minutes.  It's a matter of choice.

It is not in the least "a matter of choice".  For one thing, I'd rather let
the computer do the multiplication of 8 by 60 instead of being forced to do
it myself; computers are good at that sort of thing.  For another, my
proposal is an *upward compatible extension* to the System V syntax (which,
BTW, the item in the System V Interface Definition under "Future
Directions", where the number in TZ becomes a four-digit value of the form
"hhmm", does not seem to be).  Your proposal is not an upward compatible
extension to the System V syntax, as it involves changing the time zone
offset to minutes - i.e., EST5EDT is no longer correct.  There have already
been enough incompatible changes to UNIX by several groups with the intent
of "improving" it (Berkeley's CSRG and AT&T's USDL have both done their
share of this); let's try to keep that sort of thing to a minimum in the
future.  (I.e., don't always take the first solution to a problem that comes
to mind, or even the most aesthetically pleasing solution; sacrificing some
think time or some aesthetic merit for compatibility is almost always the
right thing to do.)

>    It may be preferable to use seconds to be on the safe side.

Given that most clocks used in everyday situations aren't accurate to the
second, the chances of a timezone offset being specified to the second are
somewhere between slim and none, unless you have an offset from UTC
specified to the second due to something like not picking up a leap second
(which I sincerely doubt anybody does).  Specifying the offset down to the
second is overkill (note that 4.2BSD's "gettimeofday" system call fills in a
structure which specifies the offset to the minute; a commendable example of
restraint).

> 5. Who puts TZ and DST into a user's environment? (Guy Harris)
> 
>    The easy answer is "whatever puts TZ there now".  It is an OS
>    specific mechanism.  "login" could do it or a user's login shell
>    upon starting up could do it.  I didn't specify in the proposal.
> 
> 6. What about utilities not run by a logged-in user? (Guy Harris)
> 
>    Such utilities should only have to use a library call to obtain
>    the timezone name (if desired) and the local time.

In this case, the library call in question had better be part of the
standard.  I presume by "the local time" you really meant "the local
timezone offset and the daylight savings time rules for that zone".  As
such, since this implies there is a "default" time zone, why not have all
the routines use this time zone if TZ is not specified in the environment?
That way, 1) programs don't have to "know" that they're going to be run in
such an environment and have the extra calls to get the "default" timezone
information added, and 2) you don't have to bother sticking TZ in the
environment unless you want to work in a timezone other than the default.

> 7. Use files to hold information about that timezone.
>    (steinmetz!davidsen and ncr-sd!greg (Greg Noel))
> 
>    Using a file with the name of a timezone won't work for Daylight
>    Saving Time rules because one timezone may span multiple countries
>    with its named unchanged...

Arthur Olson's proposal does not require the file's name to be the same as
the zone.  The zone's name is computed from information in the file.

>    For users of network file systems and diskless workstations: beware,
>    proximity does not imply same rules (for a bad dream, think of a network
>    that spans a timezone where there is only one file server and the rest
>    of the nodes are diskless -- this contrived example is hard to solve
>    with any proposal).

No, it isn't.  Here's how it could be solved, given the way Sun
sets up diskless clients:

	Have the "default time zone" be specified in a file (whether the
	file is a "profile" file which puts it in the environment, or
	a file which is read in by the "get default timezone" routine,
	or whatever is irrelevant) which is, say, in "/etc".  Make it
	a symbolic link to a file in "/private/etc".  "/private", on Sun
	systems, is a small private file system on the server; each client
	has one of its own, to hold things like "/etc/rc.boot" which sets
	the host name for the machine.  Sharing this file between all clients
	obviously won't work, so the precedent for configuration files for
	diskless workstations which can't be shared by all clients of its
	server is already established.

>    The second point is that the name of the timezone has to be known
>    somehow -- both the default timezone and, if the user selects one,
>    the non-system name.  This brings to mind an easy solution of
>    environment variables.

It may be easy, but it's not a solution, unless you can stuff this default
timezone into the environment of every process on the system.  And if you do
so in N different places, as System V currently does, it may be a solution
but it's not easy.

>   Let me close with the requirements, as I see them, for the handling of
> timezone and DST information.  It might be better to debate these instead
> of any specific proposals.

If we're going to debate the requirements, let's not see any specific
proposals until the requirements are settled, so we don't have to shoot down
proposals which either don't meet the requirements or which are more complex
than is needed to meet the requirements (or both!).

> 1. every site must have default information on its timezone and for DST
>    rules

Every *host* must have this information, as you pointed out in the example
of the diskless workstatiions.

> 2. information about the past, while it may be needed in some situations,
>    is not essential
> 3. information about other timezones and areas, while it may be needed
>    in some situations, is not essential

Would you please explain the distinction between "needed" and "essential"?
If it is truly "needed" in some situations, as opposed to "useful", it's
"essential" unless the system can do without a P1003-compatible system.

> 4. a user (or program) should be allowed to change the timezone and DST
>    information for their use only

4 1/2. a consequence of this is that a program must be able to override
       any setting the user has made and get the default timezone for 
       that machine

Volume-Number: Volume 5, Number 63