home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0008.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.9 KB
  1. From: seismo!allegra!druil!khw@sally.UTEXAS.EDU
  2. Date: Mon, 6 Jan 86 17:55:22 EST
  3.  
  4. I strongly oppose using a centralized time zone for each
  5. computer.  It is unnecessarily constricting, creates problems
  6. with networking computers together and with daylight savings, and
  7. is not necessary.
  8.  
  9. The major reason I read in Mark Horton's article for not using
  10. decentralized time zones is that security holes exist with system
  11. programs getting fooled about what time it really is.
  12.  
  13. The reason they are getting fooled is not because
  14. of the decentralized nature of the time zone setting, but because
  15. they don't keep their internal times in some standard time zone.
  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. We are running System III.  We have a calendar application.  Users
  25. were upset when the meetings they had scheduled for 8 am,
  26. (with the onset of DST) appeared for 9 am.
  27. The problem was the application was keeping stuff in local time,
  28. and not being very smart about it.
  29. A simple revision to use GMT instead fixed this problem, with
  30. the application not knowing or caring if DST is in effect or
  31. not.
  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. Programs are like people; they get jet-lag when crossing
  38. time zones too fast, and for a program one time zone is
  39. too fast, unless a lot of care has been taken in writing it.
  40.  
  41. What you want is a processor that steadily ticks along with
  42. only slight corrections to the time while running to correct
  43. clock drift.  Changing states to kill off running processes,
  44. changing the time, and restarting may be acceptable in most
  45. environments that Unix has run in currently, but we should
  46. not restrict it to these environments.  I want to be able
  47. to sell Unix to hospitals, for example.
  48.  
  49. We have been mostly lucky because savings time changes in the US at
  50. a time when there isn't much going on, and people don't
  51. notice what happens to, say, at and cron when the clock
  52. changes under them, because they don't do much at that
  53. time of day.  But with world-wide access to central computers on the
  54. horizon, and in some applications (such as hospitals) this is
  55. changing.
  56.  
  57. Networks will shortly progress to the state where
  58. a common time shared by all elements is very desirable,
  59. and this might as well be the current world standard GMT.
  60. Such a common time is the only way to prevent ambiguities,
  61. and changing centralized times to compensate for DST
  62. will introduce these ambiguities.
  63.  
  64. The problem with System III (besides rc not setting
  65. a default TZ that is passed on) is 1) the daylight
  66. algorithm is centralized.  You really want an algorithm
  67. on a per process-group basis, that allows people
  68. from multiple countries that have different daylight
  69. savings definitions to call up and get the one suitable
  70. for them.  2) The syntax for the timezone allows only
  71. multiples of hours.  Otherwise the problems come from
  72. system programs which use local time, not GMT.
  73.  
  74. If the system programs were changed to use GMT, then cat'ing
  75. their files out would not show the time in terms that the
  76. System Administrator was used to (unless s/he is located
  77. in GMT).  A filter could be used to translate these,
  78. or the SA could get used to reading GMT.  With lengthy
  79. networks, the SA should be reading in GMT anyway to
  80. keep from getting confused when troubleshooting problems
  81. with another element on the network that isn't in the same
  82. zone.
  83.  
  84. I claim that switching to a single centralized timezone
  85. is short-sighted.  It may work for most applications
  86. we have now, but it is not the way to go for the future.
  87.  
  88.         Karl Williamson
  89.         ATT ISL Denver
  90.         ihnp4!druil!khw
  91.         303-538-4583
  92.  
  93.  
  94. Volume-Number: Volume 5, Number 9
  95.  
  96.