home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0061.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  6.5 KB
  1. From: seismo!hao!asgb!devine (Bob Devine)
  2. Date: Tue, 25 Feb 86 19:58:51 mst
  3.  
  4.   First of all, sorry for the length of this article.  I've been
  5. doing job search type of things the last week.
  6.  
  7.   It appears that this will be my last posting from this site.
  8. The Burroughs Distributed Systems Group was severely cut for budget
  9. reasons.  The uucp site "asgb" (it stood for Advanced Systems Group,
  10. Boulder) will soon be no more.  In fact, there are only a few
  11. terminals left attached to any VAX.  Our site officially closed
  12. a week and a half ago.
  13.  
  14.   There has been many responses to my proposal for the handling
  15. of timezones and Daylight Saving Time rules.  Let me respond to
  16. them according to subject.  However, let me first reiterate the
  17. important ideas presented in my proposal of a month ago:
  18.  
  19.     1. a single timezone definition exists for that system;
  20.        this definition is the default
  21.  
  22.     2. timezone and DST rules are kept and passed as
  23.        environment variables
  24.     
  25.     3. a user (or program) can override the default definition
  26.  
  27.   The above can be considered a "cleaned-up" way of handling timezone
  28. compared to AT&T System III and V.  DST handling is just an analogous
  29. extension to this.  I proposed this method to deal with the coming
  30. UNIX usage throughout the world.  Specifically, the product line we
  31. were developing used UNIX and was to be offered everywhere Burroughs
  32. does business.  
  33.  
  34.   My proposal's biggest (and intended) limitation is its inability to
  35. deal with past years at all.  To do that requires a table of such
  36. changes as elsie!ado's proposes.  However, after I started collecting
  37. such rules and saw that they numbered in the thousands I decided for
  38. the simpler proposal.  If anyone wants to, they can see my collection
  39. gathered from a person from the DOT, someone at the National Bureau of
  40. Standards, and several publications from the American Federation of
  41. Astrologers.  However, any collection becomes old quickly.  For example,
  42. China just this month started using 4 timezones instead of the one
  43. centered on Bejing.
  44.  
  45.   On to the criticisms and questions:
  46.  
  47. 1. Format of proposed DST variable.  Are 0 or 2 changes per year
  48.    sufficient? (Chris Torek, Mark Horton and Andy Glew)
  49.    I believe so for all places __currently__.  The only places that
  50.    I have found to use Double Summer Time are:
  51.        Argentina     1924 and 1969
  52.        Azores        1942 (unclear)
  53.        France        some areas 1940-42
  54.              everywhere 1943-46 and 1976-77
  55.        Great Britain 1941-47
  56.        Portugal      1942
  57.        Spain         1942-1946
  58.        Tunisia       194x (unclear)
  59.  
  60.    If Double Summer Time is in modern use, four changes can be put
  61.    into the DST variable.  Re-reading my response to Chris Torek,
  62.    I see that I was unclear.  I wrote that no rules would "violate the
  63.    assumptions" made for the DST variable.  What was not clear was
  64.    the assumption that 4 changes could be used.
  65.  
  66. 2. Numerals, '-', or '+' in timezone names. (Chris Torek and Mark Horton)
  67.    I don't know.  Does anyone have a list of legal timezone names
  68.    and abbreviations (if any) as used by each country?  I have English
  69.    equivalents for some.  The TZ variable can be modified to use
  70.    field separator characters between the names and offset from UT.
  71.    A note: the sign used for the offset should match ISO standards,
  72.    which is the opposite of System V conventions.  Sorry, I don't have
  73.    the ISO document number than details this; it's in a box somewhere.
  74.  
  75. 3. "/etc/TIMEZONE" is too specific.  Use functions. (Guy Harris)
  76.    For the purpose of P1003, Guy is right.  To avoid the confusion
  77.    of all new CTIME(3C) functions, the existing functions should be
  78.    kept though with modifications.  A problem lurks in the use of
  79.    the ctime() function where programs copy the returned string into
  80.    a too short array.
  81.  
  82. 4. Proposed TZ format is too unlike Sys V's. (Guy Harris)
  83.  
  84.    System V's use of difference is hours is just plain wrong for
  85.    many places (eg., Dominican Republic, Iran, and Saudi Arabia
  86.    where local custom dictates midnight is when the sun sets).
  87.    I proposed using just minutes.  Guy proposes the form "[+/-]H[:m]"
  88.    where "H" is hours and "m" is minutes.  It's a matter of choice.
  89.    It may be preferable to use seconds to be on the safe side.
  90.  
  91.  
  92. 5. Who puts TZ and DST into a user's environment? (Guy Harris)
  93.  
  94.    The easy answer is "whatever puts TZ there now".  It is an OS
  95.    specific mechanism.  "login" could do it or a user's login shell
  96.    upon starting up could do it.  I didn't specify in the proposal.
  97.  
  98.  
  99. 6. What about utilities not run by a logged-in user? (Guy Harris)
  100.  
  101.    Such utilities should only have to use a library call to obtain
  102.    the timezone name (if desired) and the local time.
  103.  
  104.  
  105. 7. Use files to hold information about that timezone.
  106.    (steinmetz!davidsen and ncr-sd!greg (Greg Noel))
  107.  
  108.    Using a file with the name of a timezone won't work for Daylight
  109.    Saving Time rules because one timezone may span multiple countries
  110.    with its named unchanged (eg., Canada and USA) yet the countries may
  111.    have different rules for daylight saving time.  Furthermore, within
  112.    one country, not all areas within a timezone use DST the same way
  113.    (eg., Indiana, Arizona).  A two dimensional grid of timezones and
  114.    countries might be possible but this would probably get unwieldy quickly.
  115.    For users of network file systems and diskless workstations: beware,
  116.    proximity does not imply same rules (for a bad dream, think of a network
  117.    that spans a timezone where there is only one file server and the rest
  118.    of the nodes are diskless -- this contrived example is hard to solve
  119.    with any proposal).
  120.    The second point is that the name of the timezone has to be known
  121.    somehow -- both the default timezone and, if the user selects one,
  122.    the non-system name.  This brings to mind an easy solution of
  123.    environment variables.
  124.  
  125.  
  126.   Let me close with the requirements, as I see them, for the handling of
  127. timezone and DST information.  It might be better to debate these instead
  128. of any specific proposals.
  129.  
  130. 1. every site must have default information on its timezone and for DST rules
  131. 2. information about the past, while it may be needed in some situations,
  132.    is not essential
  133. 3. information about other timezones and areas, while it may be needed
  134.    in some situations, is not essential
  135. 4. a user (or program) should be allowed to change the timezone and DST
  136.    information for their use only
  137. 5. because the local time conversion is used often, it should be fast
  138. 6. changes to the system-default information should be easy to make
  139.  
  140. So long,
  141. Bob Devine
  142. (home phone: 303/772-2410)
  143.  
  144. Volume-Number: Volume 5, Number 62
  145.  
  146.