home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0010.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  4.0 KB
  1. Date: Tue, 7 Jan 86 16:56:17 est
  2. From: seismo!cbpavo.cbosgd.ATT.UUCP!mark@sally.UTEXAS.EDU (Mark Horton)
  3. Organization: AT&T Bell Laboratories, Columbus
  4.  
  5. >What you want is a processor that steadily ticks along with
  6. >only slight corrections to the time while running to correct
  7. >clock drift.
  8.  
  9. Exactly.  This is what UNIX does now, and I am not suggesting
  10. any changes to this behavior.  What V7 does is keep internal
  11. time as time_t in GMT, and next to it are a couple of flags
  12. representing offset from GMT and a daylight flag.  These two
  13. flags don't affect the time(2) call, they are just passed to
  14. the ctime(3) routine when it asks the kernel for them with ftime(2).
  15. The local time is then calculated, taking these into account.
  16.  
  17. >I claim that all programs that care about time should keep all
  18. >times internally in GMT (or UCT or whatever you want to call it), and
  19. >convert from/to local time on input/output.  This is, in fact, the
  20. >only way they can not be upset when the time zone of the computer
  21. >suddenly changes (which in effect it does when daylight savings
  22. >comes and goes).
  23.  
  24. What do you mean "keep all times internally"?  If you're referring to
  25. such things as the L.sys UUCP database, I think it's obvious that this
  26. has to be in local time (not only because of the potential for human
  27. error otherwise, but because you'd have to change it by hand every time
  28. you go into or out of daylight time if it were in GMT.)  If you're
  29. referring to local timestamps, then certimely a time_t (seconds since
  30. Midnight, Jan 1, 1970, GMT) is a good way to do this, if you don't have
  31. to represent dates before 1970, like birth dates.
  32.  
  33. >My understanding of the centralized proposal is that this
  34. >would not longer be possible, that the computer itself would
  35. >change times when DST started and ended.
  36.  
  37. Not at all.  What changes is the way the time is displayed to users,
  38. displayed in log files, and interpreted when a user inputs a time.
  39. Clearly such uses should be in the local time zone.  (Whether this means
  40. "local" for the machine or for the user is apparently an open issue.)
  41.  
  42. I gather you are not suggesting that you have a need for a particular
  43. process (or user) to indicate he's in a different time zone from the
  44. system default, although apparently at least one other person has
  45. indicated that on MULTICS people do this.  I wonder if anybody uses
  46. this ability on UNIX?
  47.  
  48. >We have been mostly lucky because savings time changes in the US at
  49. >a time when there isn't much going on, and people don't
  50. >notice what happens to, say, at and cron when the clock
  51. >changes under them, because they don't do much at that
  52. >time of day.  But with world-wide access to central computers on the
  53. >horizon, and in some applications (such as hospitals) this is
  54. >changing.
  55.  
  56. If I were running a 24 hour critical application, such as a hospital,
  57. I would demand that all time logs be 100% correct.  Since the real
  58. clock jumps forward or backward by an hour twice a year, the logs had
  59. better do this too (and include the time zone so you can tell if 2:30 AM
  60. was the first or second 2:30 that night.).  UNIX already does this quite
  61. nicely (at least in the USA, until Congress decides to change the rules.)
  62.  
  63.     Mark
  64.  
  65. [ A couple of readers have taken the moderator to task for posting
  66. the article to which Mark replies here, since it was clearly based
  67. on a misunderstanding both of what Mark proposed and what UNIX does.
  68. I posted it because I thought it would give Mark a good opportunity
  69. to clarify the points on which both that and a previous article showed
  70. confusion.  I believe he does so ably here.  However, I will probably
  71. be more strict in the future in winnowing such submissions as the one
  72. to which he is replying.
  73.  
  74. I solicit further input on this as well as any other thoughts by
  75. readers on how moderation is done in this newsgroup.  For instance:
  76. the V5N11 is in the Subject line because one notes reader wanted it
  77. there; yet another notes reader complains that it interferes with the
  78. subject kill capability of notes.  Other opinions?  -mod ]
  79.  
  80. Volume-Number: Volume 5, Number 11
  81.  
  82.