home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0015.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  4.4 KB  |  98 lines
  1. [ Let me reiterate something that many people do not seem to realize:
  2. UNIX has *always* kept internal time in GMT; that is not an issue.
  3.  
  4. Joe Yao's summary below covers most of the actual issues.
  5. If you do not agree with parts (or all) of it, submit your comments.
  6. But no flames please.  This is a technical discussion newsgroup,
  7. not a boxing ring.  -mod ]
  8.  
  9. Date: Sat, 11 Jan 86 15:08:53 est
  10. From: seismo!hadron!jsdy@sally.UTEXAS.EDU (Joseph S. D. Yao)
  11. Organization: Hadron, Inc., Fairfax, VA
  12.  
  13. Following this discussion, it is clear that a number of different
  14. things are needed.  We need:
  15. (1) a way to be sure that logs are kept in one, single, system-
  16.     appropriate time;
  17. (2) a way that people can set times reported to them to be meaningful;
  18. (3) a way that people can enter times in a way that is meaningful to
  19.     the system, but also understood correctly by the machine (with at
  20.     or cron or remind as cases in point);
  21. (4) a standard for individual machines to tell (over nets) other
  22.     machines what time they think it is;
  23. (5) perhaps an 'rtime' facility, to know what time it is elsewhere?;
  24. [ Much work has been done on 4 and 5.  I will post a followup article.  -mod ]
  25. (6) a way to be sure that processes can't override system time limits
  26.     by changing the time (such as with UUCP);
  27. (7) a way for system managers to be able to specify either a default
  28.     "time zone" or a way of figuring out (from 0 to infinity) what
  29.     the time really is/was.
  30. Probably several other things, as well.
  31.  
  32. It's not clear that only one mechanism will take care of all of these.
  33. For instance, agreeing to allow a time zone specifier in input formats
  34. certainly addresses a lot of these.  But, what about "Pothole IL Local
  35. Standard Time" (EST+0:04:17)?  We will need some way to figure out time
  36. zones that are not exactly integral hours off from UCT.  I don't like
  37. particularly the idea of user-written time agents, partly because I
  38. know how often "professional software engineer"s make little (or big)
  39. mistakes, especially in the area of not testing all boundary
  40. conditions, and I can imagine those who aren't constantly engineering
  41. software might make even more.  Perhaps we can figure out a way to
  42. specify the rules for a time zone in a user-writable table, so that
  43. if politicians decide to mess us up even further we can just send a
  44. few lines of table over the net to patch the algorithm.  Note that
  45. the algorithm  s h o u l d  work "from 0 to infinity."
  46.  
  47. [ It should also work from zero to negative infinity.  -mod ]
  48.  
  49.                             And, of course,
  50. each process group (or maybe process) might want to have an idea of
  51. what its own expression of time is; but should be able to get at the
  52. system's idea, too.  (Just for Rob Pike, a date -[lsv]?)  As an under-
  53. lying time, of course, it is good to get machines to think and talk
  54. to each other in UCT (GMT), as radio operators do, since that is one
  55. of the things it was invented for!
  56.  
  57. [ Once more:  internal (kernel) UNIX time format is GMT, and that's also
  58. what has always been used on networks like the ARPANET for communication
  59. between systems, whether UNIX, TOPS-20, Multics, or whatever.  -mod ]
  60.  
  61.                     It is (so far) independent of
  62. astronomical or political changes in the "real" time.  We'll see how
  63. this works once we start talking in terms of relativistic distances
  64. [;-)].
  65.  
  66. [note: deference to rob pike, whose talk "cat -v considered harmful"
  67. was actually a good expose' on creeping featurism.  -jsdy-]
  68.  
  69. [ The talk of that name was originally given at the Toronto (Summer 1983)
  70. USENIX Conference and has an abstract in those proceedings.  A paper in
  71. the same vein is:
  72.  
  73.           Pike1984.       R. Pike and B. W. Kernighan, "Program Design
  74.                           in  the  UNIX  Environment," [BLTJ1984], pp.
  75.                           1595-1605, 1984.
  76.  
  77. That journal issue is now selling for a reasonable price, I hear.
  78. (I don't know what the price is or what the telephone number is.)
  79.  
  80.           BLTJ1984.       BLTJ,   "The   UNIX   System,"   AT&T   Bell
  81.                           Laboratories Technical Journal, vol. 63, no.
  82.                           8, American Telephone and Telegraph Company,
  83.                           Short Hills, N.J., October 1984.
  84.  
  85. And if you like the article, you'll love the book:  :-)
  86.  
  87.           Kernighan1984.  Brian W. Kernighan and Rob  Pike,  The  UNIX
  88.                           Programming    Environment,   Prentice-Hall,
  89.                           Inc., New Jersey, 1984.
  90.  
  91. -mod ]
  92. -- 
  93.  
  94.     Joe Yao        hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
  95.  
  96. Volume-Number: Volume 5, Number 16
  97.  
  98.