home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0057.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.6 KB
  1. Date: Sat, 22 Feb 86 21:14:28 cst
  2. From: ihnp4!uiucdcs!ccvaxa!aglew@SEISMO.CSS.GOV (Andy Glew)
  3.  
  4. I do not know if double daylight savings has ever been used, 
  5. but I heard a man from Canada's NRC talking about it on CBC radio last year.
  6. The NRC is hoping that the US will go to DST earlier and stay later,
  7. and from that it is only a short step to double time.
  8. This makes better sense the closer you get to the pole.
  9. I do know that several industries in Britain in WWII went to effective
  10. double daylight savings time, by having people report to work earlier
  11. in deepest summer (which is what we should do anyway).
  12.  
  13. What's all the fuss about, anyway? All times should be recorded in GMT,
  14. since it's the closest thing we have to a standard clock.
  15. Timezone information should only be used for local printing of the time
  16. - dates, ls, etc. For this, the environment variable would be useful.
  17.  
  18. [ Several people have described what the problems are at length.
  19. Since it's been a while, naturally there are people just starting
  20. to follow the discussion who missed its beginning.  Perhaps I should
  21. repost one of the explanatory articles.  So, a small poll:  If you've
  22. come in late and want to know what all the fuss is about, send me
  23. a note.  If you've been following the discussion all along and remember
  24. a particular specification of the problem which was most clear to you,
  25. let me know.  If I get enough of the former I will repost an
  26. explanatory article, possibly chosen according to the latter.  -mod ]
  27.  
  28. Timestamps MUST be recorded in GMT, for projects that exchange code across
  29. timezones.
  30.  
  31. [ The UNIX kernel has always kept internal time in GMT, as have most
  32. other operating systems (VMS seems to be an exception).  There are,
  33. however, programs which write text timestamps in local time.  -mod ]
  34.  
  35. It is conceivable that knowing what time of his local day the author last
  36. modified his code might be useful, but instead of carrying a timezone
  37. indication, why not carry a true location around, like latitude/longitude,
  38. and look that up in a database (although it might get hairy for spaceships
  39. travelling near c :-).
  40.  
  41. [ Timezones change per latitude and longitude. -mod ]
  42.  
  43. Even hairier idea:  have we considered non-24 hour days? Someday, someone is
  44. going to have computers on the moon; they may still be running UNIX (and
  45. Fortran, and Cobol) at that time, and there's no guarantee that they'll
  46. stick to a 24 hour day. There've been a lot of studies that show that men
  47. in isolation go to a 28-30 hour cycle, and without the sun rising to keep
  48. you in synch, there's no reason not to change the definition of "day".
  49. GMT will probably still be kept, but local time takes on a whole new meaning.
  50. Maybe just leave an escape in any timezone environment variable for
  51. local time conversions that don't simply consist of adding an offset?
  52.  
  53. [ Doubtless it will happen, but probably not within the effective
  54. life of the current P1003 proposed standard.  I suggest the new
  55. INFO-FUTURES list for such discussions.  I will repost the announcement
  56. from UNIX-WIZARDS for it as the next article.  -mod ]
  57.  
  58. Andy "Krazy" Glew. Gould CSD-Urbana. 
  59. UUCP: ...!ihnp4!uiucdcs!ccvaxa!aglew
  60. ARPA Internet: aglew@gswd-vms.ARPA
  61.  
  62. [ PS:  Other than interpolating comments, there are exactly two things
  63. which I can't resist doing to submitted articles before posting them
  64. and without asking their authors first:  fixing obviously incorrect
  65. spelling; and fixing incorrect network addresses, like UUCP addresses
  66. given as being for USENET or old-style ARPANET addresses which won't
  67. work anywhere in the ARPA Internet where domain nameservers are in use.
  68. -mod ]
  69.  
  70. Volume-Number: Volume 5, Number 58
  71.  
  72.