home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0065.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  5.2 KB
  1. Date: Tue, 4 Mar 86 16:02:04 PST
  2. From: Snoopy <seifert%hammer.uucp@CSNET-RELAY.ARPA>
  3.  
  4. Once upon a time, I posted a survey, asking which method people
  5. would prefer for allowing a user to override the system default
  6. timezone.  I suggested a ~/.daterc file, and/or environment variables.
  7.  
  8. I received 15 replies.  The summary of votes is:
  9.  
  10.         environment variables        -  4 votes
  11.         either                -  3 votes
  12.         "not ~/.daterc"            -  1 vote
  13.         use GMT for everything        -  1 vote
  14. "take it out of the kernel and put it in libc"    -  1 vote
  15.         other                -  1 vote
  16.         misunderstandings        -  4 (at least)
  17.  
  18. A number of people were concerned with performance, since lots of
  19. programs use timestamps.  They were concerned that opening a file
  20. would slow things down.
  21.  
  22. Some selected replies, edited for brevity:
  23. ------------------------------------
  24. From: ihnp4!cbosgd!cbpavo.cbosgd.ATT.UUCP!mark
  25.  
  26. System V has a default (which always
  27. seems to be the time zone of the developers of the system, so that
  28. the developers will never find any bugs that only show up in non-default
  29. time zones) and overrides it with the TZ environment variable.  This
  30. has some horrible properties:
  31.  
  32.   (1) People who don't use the Bourne shell, and hence don't source
  33.       /etc/profile, don't get a TZ.  This includes csh and uucico.
  34.   (2) Programs run from crontab don't get a TZ.
  35.   (3) Programs run single user don't get a TZ.
  36.   (4) An individual can change his TZ to defraud the system.  For
  37.       example, a UUCP L.sys may restrict a certain long distance
  38.       call to night hours, but by setting your time zone to some
  39.       far off part of the world, you can dial out during the day.
  40.  
  41. [...]
  42.  
  43.    (1) "time right now" must be fast for logging
  44.    (2) "time of some date this year" should be reasonably fast for ls -l.
  45.    (3) "time of some date some previous year" can be slow.
  46.  
  47.     Mark
  48. ----------------------------------
  49. From: hp-pcd!hp-sdd!sdcsvax!bmcg!asgb!devine
  50.  
  51.   My choice looks like:
  52.  
  53.     $TZ=MST-7    # name of timezone and difference from Univeral Time
  54.     $DST=1        # how much to adjust for DST; ==0 if no DST is used
  55.     $DST_START=(when daylight saving starts)
  56.     $DST_STOP=(when daylight saving stops)
  57.  
  58. Bob Devine
  59. Burroughs / Boulder, CO.
  60. -------------------------------
  61. From: sequent!riacs!seismo!ut-sally!cyb-eng!howard
  62.  
  63. Whatever happened to the concepts of dynamic linking, true interprocess
  64. communication, and "lightweight processes"?  If your operating system
  65. is frozen or hostile and you care about D.S.T., then dynamically loading
  66. a library module might be appropriate.  If the o.s. is frozen/hostile and
  67. you don't care, use something like "/etc/daterc" which can be overridden
  68. by $TZ.  If you're writing/modifying an o.s., consider dynamically-loaded,
  69. reentrant library routines and memory management hardware to support it.
  70. Of course, a more practical o.s. approach would be to have a date server:
  71. just set up a socket to your favorite date-server port and go get it.
  72.  
  73. ------------------------------------
  74. From: tektronix!allegra!clyde!watmath!utzoo!ecrhub!ecr1!peterc
  75.  
  76. In studying this problem a while ago, I found I needed three environment
  77. variables.  They could have been encoded into one, of course, but that
  78. makes it harder for the user to set up right.  I found the following
  79. were necessary:
  80.  
  81. TIMEZONE:  a comma-separated list of the time zones that apply.
  82.         e.g. TIMEZONE=EST,EDT
  83. TIMEDIFF:  a comma-separated list of the number of minutes west of GMT (east if
  84.         negative) the corresponding time zone is.
  85.         e.g. TIMEZONE=480,540
  86. TIMECHG:   a comma-separated list of the dates on which time changes occur.
  87.         It is assumed that at midnight on January 1st each year, we
  88.         are in the initial time zone (e.g. EST), and then progress
  89.         through the others in sequence, then backwards to the original.
  90.         The time change dates are specified in the form
  91.             mm/dd+n
  92.         where "mm" is the month (1-12), "dd" is the day (1-31), and
  93.         the "+n" (or "-n") causes that date to be moved forward
  94.         (backward) to the appropriate day of the week (e.g. 4/24+0
  95.         means the first Sunday on or after April 24th).
  96.  
  97. I prefer environment variables for reasons of speed.  However, the current
  98. UNIX scheme is not adequate, for several reasons:
  99.     - it does not provide the flexibility needed, because everything
  100.         is hard-coded.
  101.     - it does not satisfy the real-world requirements.  In particular,
  102.         it does not take into account things like the double
  103.         daylight savings time used in much of Europe.
  104.  
  105. Even the scheme I propose here is not really adequate, because it only accounts
  106. for the current year, which may not be suitable for other years.  A more general
  107. scheme could be built by adding special cases for unusual years:
  108.  
  109.     TIMECHG=4/24+0,10/25+0;1974-1975:.....;.....
  110.  
  111. I.e. make the first set of values (up to the first ';') the rule that applies
  112. in the current year, and any other unspecified year.  Then add special cases
  113. for other years.
  114.  
  115. All this starts to get complex, ugly and unpleasant to set up and program.
  116. That is the way it is.  Sir Stanford Fleming established a wonderful system
  117. when he defined Standard Time.  I hope he didn't expect it to stay that way.
  118.  
  119. ------------------------------
  120. This is getting prettty long, so I'll describe what I'm actually doing in
  121. a future article.
  122.  
  123. Snoopy
  124. tektronix!tekecs!doghouse.TEK!snoopy
  125.  
  126. Volume-Number: Volume 5, Number 66
  127.  
  128.