home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0006.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.9 KB
  1. Date: Sun, 5 Jan 86 00:52:37 est
  2. From: seismo!harvard!think!mit-eddie!barmar@sally.UTEXAS.EDU (Barry Margolin)
  3.  
  4. In response to Mark Horton's posting about time zones:
  5.  
  6. Multics has long had per-process time zones, and they are extremely
  7. heavily used on systems which have users logging in from across the
  8. country (or world, in some cases).  Most of the people in my Cambridge,
  9. MA office use a system in Phoenix, AZ quite a bit, and I am considered
  10. unusual because I don't bother to set my time zone to EST.
  11.  
  12. One good argument for only having system zones that was made was about
  13. software that makes critical decisions based on the time of day (the
  14. example was a wrapper for uucico that makes sure the call isn't being
  15. made during the day).  The solution is for such programs to ignore
  16. the TZ inherited from the caller, perhaps using a new system call
  17. that gets the system-default time zone.  We don't have this problem
  18. on Multics because security decisions are either made in daemon processes
  19. or in inner-ring subroutines, and per-process variables are actually
  20. per-process per-ring, so the user's personalization generally doesn't
  21. affect secure domains.
  22.  
  23. One apparent difference in time zone semantics between Unix and Multics
  24. is the behavior of past/future times.  On Multics, the time zone in which
  25. a date/time should be converted to GMT is an INPUT parameter, defaulting
  26. to the process' time zone; we do not attempt to determine whether DST
  27. was in effect on the date being converted.  We therefore have no need
  28. for complex DST calculation at run time.  Whether this is considered
  29. right or wrong is mostly a matter of taste; I know of a other systems
  30. that have chosen to dynamically determine DST.  In general, a subroutine
  31. for converting a time in a specified time zone to GMT is a useful
  32. facility; for instance, to interpret Date fields in mai headers.
  33.  
  34. I have been thinking about WHY many systems try to determine the
  35. DST state at a given time.  This is because they only store the binary
  36. form of the time in various system databases, and attempt to display
  37. the user-relative time at which the event took place (for instance,
  38. so that you can tell that it was very late when the user modified
  39. a file, so the bugs are probably because he was tired).  The "right"
  40. way to get this effect would be to store the user's personal time zone
  41. in addition to the binary time.  Display routines would display the
  42. time in the retrieved time zone, rather than trying to guess the appropriate
  43. time zone.  In the context of Unix standardization, this is probably
  44. unreasonable, as it is not consistent with any existing version of Unix.
  45. It also has the problem that it increases the size of times stored in
  46. many system databases, which may be considered wasteful for the little
  47. benefit that this approach provides.
  48.     Barry Margolin
  49.     ARPA: barmar@MIT-Multics
  50.     UUCP: ..!genrad!mit-eddie!barmar
  51.  
  52. Volume-Number: Volume 5, Number 7
  53.  
  54.