home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0054.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.7 KB
  1. From: seismo!kobold!ncr-sd!greg
  2. Date: Thu, 20 Feb 86 19:54:17 pst
  3. Organization: NCR Corporation, Rancho Bernardo
  4.  
  5. In article <4186@ut-sally> Bob Devine proposes a standard method to hold
  6. the timezone information, which keeps the information in a file in a format
  7. suitable for interpretation by the (Bourne) shell.
  8.  
  9. In article <4190@ut-sally.UUCP> Guy Harris replies:
  10. >        ....
  11. >Too specific.  The standard should not give all the implementation details.
  12. >        ....
  13. >Unnecessarily incompatible with System V, which specifies the offset from
  14. >        ....
  15. >Not sufficient.  The routines that convert between GMT and local time can be
  16. >        ....    
  17. >What puts TZ and DST into the environment of each user?  If it's not done by
  18. >        ....
  19. >And what about utilities not run by a logged-in user?  Must they look in
  20. >        ....
  21.  
  22. I agree; the scheme is flawed by all of those problems and more.  I don't
  23. have any skill with words (in the way they are used in specifications), but
  24. I would propose that any scheme adopted by the standards commitee should have
  25. the following requirements:
  26.   -  There should be a way that a system administrator could specify a global
  27.      (system-wide) default that is not process-tree related.  In other words,
  28.      it can't depend upon something in the environment.
  29.   -  There should be a way that this can be overridden so that non-default
  30.      timezones can be supported.  Presumably, this can be done on a process-
  31.      tree basis; i.e., it can be carried in the environment.
  32.   -  It should be possible to handle things like multiple timezone changes
  33.      per year (double daylight savings, like during WWII) and timezone changes
  34.      that are not exactly one hour (didn't Newfoundland once have a daylight
  35.      savings change of 1.5 hours?).
  36.  
  37. Personally, I think a better scheme is the one presented here a month or so
  38. ago, where the timezone information lives in a directory with one file for
  39. each timezone and with the standard timezone linked to a default name.  A user
  40. could override the default by specifying one of the files in an environment
  41. variable, or roll his own file and specify the full path name.  The file
  42. would contain:
  43.   -  The timezone offset and default name.
  44.   -  The rules for the normal conversion and the name for it.
  45.   -  Exceptional periods, the offset, and the name.
  46. Here I am being too specific myself, but I wanted to point out that Bob Devine
  47. has done us a great service by articulating a mechanism for describing the
  48. normal conversion (the second point above); whether this information is to
  49. be included in the file and processed on the fly or pre-processed by some
  50. program into a binary table that can be evaluated quickly is an implementation
  51. consideration.
  52.  
  53. -- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA
  54.  
  55. Volume-Number: Volume 5, Number 55
  56.  
  57.