home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v6 / text0029.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  4.2 KB  |  97 lines
  1. Summary of time zone discussion (and other material) in mod.std.unix Volume 5.
  2. The time zone discussion was in response to a request in P1003 Appendix A.3.
  3. The numbers in parentheses like (N3) correspond to article number within
  4. Volume 5.
  5.  
  6. The *problem* was first stated by Mark Horton (N3).
  7.     * GMT/local time disparities exist in the real world:
  8.     Internal system time must be GMT (N11) as used by make (N6), etc.
  9.     Many log files are in local time, e.g., RCS, SCCS (N15).
  10.     Users want to see dates displayed in local time (N3).
  11.     Some parameter files are in local time, such as
  12.         UUCP's L.sys (N5), crontab (N13), and at (N69).
  13.     Conversions should work for dates from at least 1 Jan 1970 (N26)
  14.         (for ls, SCCS, RCS, other logs) to near future
  15.         (L.sys, crontab, at) (N65).
  16.     * Network/dialup logistics:
  17.     Synchronization of networked hosts also requires internal GMT (N17).
  18.     Some network-related logs should perhaps be in GMT (N10).
  19.     Users may be in different timezones than hosts (N7, N14, N13).
  20.     Client workstations may be in different time zones than servers (N63).
  21.     * Politics in the real world sets time zones:
  22.     There are many standard one-hour-from GMT timezones (STs);
  23.         some of them may have different names in different countries.
  24.     There are many Dalight Savings Times (DSTs) related to STs,
  25.         usually by adding one hour.
  26.         These DSTs differ even within the same ST (N63).
  27.         Double daylight savings time is sometimes used (N62, N58).
  28.         Even daylight losing time is plausible (N51, N65).
  29.     Sometimes the DST offset from ST is not integral hours (N28).
  30.     There are local times which are not DSTs
  31.         and also not integral hours from GMT (N19, N13).
  32.     Offset precision of minutes is necessary (N19) but seconds not (N63).
  33.     ST may change at any time (China switching to several zones, N62).
  34.     DST may change at any time and with little notice (Australia, N65).
  35.         or for brief periods (U.S. presidential elections, N27).
  36.     Timezone names may conflict (Bering Strait Time/British Summer Time)
  37.         or be non-alphabetic (N54, N48).
  38.  
  39. Some *deficiencies* of existing implementations (N3).
  40.     * V7/BSD: inefficiency of system call.
  41.     * System III/V: initialization and security (N3, N66, N63, N4, N50);
  42.     one hour precision is not enough (N63).
  43.     * both: DST tables wired into kernel or library, respectively.
  44.  
  45. Proposed *solutions*.
  46.     * Early proposals by Kenneth Almquist (N24) and Bob Devine (N47)
  47.     were very useful for discussion but flawed.
  48.     * Interface as proposed by Robert Elz (N65):
  49.     Three conversions sufficient:  GMT, default local, user's local (N55).
  50.     Timezone format left to the implementation.
  51.     Timezone in environment allowed.
  52.     Default initialization and security provided.
  53.     (A routine to translate timezone name to offset possibly useful (N67).)
  54.  
  55. Proposed *implementation* by Arthur Olsen (N68,N57) since posted to mod.sources.
  56.     * Inspired Elz's interface and is sufficient for it (N65).
  57.     * Jack Jansen's implementation would also fit Elz's interface (N65).
  58.     * Miscellaneous implementation criteria:
  59.     Should not be shell-specific (N49).
  60.     Should not put timezone offset in u-area (N22, N21, N20).
  61.     Efficiency requirements (N66):
  62.         conversion    of present time fast for logging,
  63.             of near past pretty fast for "ls -l",
  64.             of distant past may be slow.
  65.     * A particular implementation may be broad or narrow,
  66.     depending on the intended market (N65, N63).
  67.  
  68. Far *future* considerations.
  69.     * Machines are currently considered stationary (N60).
  70.     * Days may not be of 24 hours (N58).
  71.     * Announcement of info-futures list (N59).
  72.  
  73. Other topics in mod.std.unix Volume 5, with numbers of the
  74. corresponding sections of the IEEE 1003.1 Trial Use Standard:
  75.  
  76. setuid and environment clearing (N39, N31) 3.1.2.
  77. setuid switching (N46, N45, N44, N43) 4.2.2.
  78. ex-directory (N12, N8)
  79. directory umask 5.3.3, 5.6.1.
  80.     motivation (N35, N23, N22)
  81.     objections (N34, N33, N25)
  82.     proposals to use .cshrc (N30, N35, N29)
  83.     clarifications:  not per cwd (N38); process umask remains (N40)
  84.     philosophy (N42, N37)
  85.     solution (N41)
  86. The IEEE 1003 Committee
  87.     and mod.std.unix (N36, N33, N35)
  88.     Draft 6 (N2)
  89.     meetings:  Denver (N18); Florence (N71).
  90. administrativia (N1, N30).
  91. guest moderator (N71, N70).
  92.  
  93. End of summary of mod.std.unix Volume 5.
  94.  
  95. Volume-Number: Volume 6, Number 30
  96.  
  97.