home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0055.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.0 KB
  1. Date: Thu, 20 Feb 86 13:11:50 est
  2. From: Davidsen <seismo!rochester!steinmetz!davidsen>
  3.  
  4. I posted some thoughts on TZ previously, but I don't believe they got out,
  5. due to a mail problem at that time. Forgive me if you've heard this before.
  6.  
  7. Some of the problems with TZ are:
  8.     1) non-standard names and abbreviations
  9.     2) strange DST rules
  10.     3) (1) and (2) change or may be added to.
  11.  
  12. Posible Solution #1:
  13. -------------------
  14.  
  15.   One method of solving these problems would be to use the value of TZ as
  16. the name of a file in a special directory. These files would be
  17. executable, and given the current date and time in GMT would return the
  18. number of minutes to be added to GMT for that timezone (obviously the
  19. return value is signed).
  20.  
  21. Drawbacks:
  22.   The only obvious one I see is overhead. A directory search + execution
  23. is not nearly as nice as just getting a number from the environment. I
  24. don't have a good idea what it would add as a percentage to the execution
  25. time of localtime(). Since the time may change at any given instant, the
  26. system can not just execute each program once and save the result.
  27.  
  28. Advantages:
  29.   Any number of timezones may be used, and timezones may be added or
  30. deleted easily. If performance is really an issue (I'm not convinced
  31. either way), then the directory could be cached in some way.
  32.  
  33.   The algorithm may be easily changed and any level of complexity can be
  34. handled. Programmers can handle more complexity than politicians.
  35.  
  36. Posible Solution #2:
  37. -------------------
  38.  
  39.   Add another form of the TZ variable which contains all the information
  40. needed to handle the current algorithm. One posible form of this would be:
  41.     TZ=M:D:DOW:h:m:Name/Offset [;TZ=M:D:DOW:H:M:Name/Offset ...]
  42.  
  43. Where: (times in GMT)
  44.      M - month of the change
  45.      D - date of the change, as a value or range (ie "14" or "14-20")
  46.    DOW - day of the week, a value, range, or "*".
  47.      h - hour of the change
  48.      m - minute of the change
  49.   Name - the correct abbreviation for "date", etc.
  50. Offset - signed minutes to add to GMT
  51.  
  52. Advantages:
  53.   This would be faster than posible solution #1.
  54.  
  55.   The string can contain any number of changes.
  56.  
  57.   Portable (all change times in GMT), and users at sites on site specific
  58. time can "roll their own".
  59.  
  60.   Covers the case where two locations want to use the same abbreviation
  61. for "their" timezone. Note that this keeps the computer from getting
  62. confused, not the user.
  63.  
  64. Disadvantages:
  65.   May not be able to handle some future really complex algorithm,
  66. particularly one based on something like phase of the moon. However, this
  67. can be updated on a yearly basis.
  68.  
  69.   Ugly, hard to read.
  70.  
  71. Summary
  72. -------
  73.   These are proposals for comment. Since I have not presented them as
  74. final solutions, technical comments are more useful than raving flames.
  75. They are not intended to address the problem of what time is used for
  76. crontab, at, and uucp calls, but I see no reason to think that either
  77. solution would exacerbate these problems, in fact solution #1 might be set
  78. to always return local time (and ignore TZ) if the caller was root, bin,
  79. uucp, etc.
  80.  
  81. Volume-Number: Volume 5, Number 56
  82.  
  83.