home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0027.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  1.5 KB  |  38 lines
  1. >From: pyramid!pyrcorp!ncr-sd!greg
  2. Date: Sat, 1 Feb 86 22:45:20 pst
  3. Subject: Re: TZ and TERM per process
  4. Organization: NCR Corporation, Rancho Bernardo
  5.  
  6. >>From: floyd!opus!ka@SEISMO.CSS.GOV (Kenneth Almquist)
  7. >Date: Tue, 28 Jan 86 21:46:36 EST
  8. >Organization: Bell Labs, Holmdel, NJ
  9. >
  10. >This article proposes a method of handling time zones which I think
  11. >meets all the requirements that have been mentioned.
  12. >
  13. > [ a scheme where timezone information is kept in a binary table
  14. >   and read in upon demand.  Also includes a clever technique for
  15. >   allowing users to use non-local timezones while permiting system
  16. >   programs to still run in local time. ]
  17. >
  18. >Any problems with this?
  19.  
  20. An interesting idea; I'd like to see it explored further.  The impact
  21. would not seem to be great, there are minimal changes to existing code,
  22. it allows flexibility in the choice of timezone, and it has a system-wide
  23. default that isn't compiled in.
  24.  
  25. There's one change I would suggest: the offset for each daylight savings
  26. time should be specified independently; sometimes the clock shift is
  27. not exactly one hour -- there are some areas with double daylight
  28. savings (two hours different), for example.  The name of the zone may
  29. have to be specified, as well.  Perhaps a better way would be to have
  30. some entries that compactly represent the usual case (one hour offset,
  31. standard name) and then have some provision for non-standard offsets
  32. and names.
  33. -- 
  34. -- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA
  35.  
  36. Volume-Number: Volume 5, Number 28
  37.  
  38.