POSE proposal for TZ

[Moderator, John Quarterman]

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