home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0059.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  1.9 KB
  1. Date: Sun, 23 Feb 86 23:54:47 PST
  2. From: seismo!s3sun!sdcsvax!sdcsvax.UCSD.EDU!allyn (Allyn Fratkin)
  3.  
  4. In article <4239@ut-sally.UUCP>, davidsen@steinmetz.UUCP (Davidsen) writes:
  5. >   One method of solving these problems would be to use the value of TZ as
  6. > the name of a file in a special directory. These files would be
  7. > executable, and given the current date and time in GMT would return the
  8. > number of minutes to be added to GMT for that timezone (obviously the
  9. > return value is signed).
  10.  
  11. Problem here: on most unix systems the parent only gets the lower eight
  12. bits of the exit value.  This would mean max/min values of 127/-128.
  13. Not very practical if the value is supposed to be in minutes.
  14. Fine if the return value is in hours, though, but then you're still 
  15. leaving parts of the world out.  Besides, we've pretty much decided that
  16. we should at least have precision in minutes.
  17.  
  18. Of course, we could make the precision HALF-hours.  This is kind of silly,
  19. but is there anywhere in the world whose time is not an integral number of
  20. half hours away from GMT?
  21.  
  22. [ The canonical example is Saudi Arabia, which has other problems, too. -mod ]
  23.  
  24. By the way, I definitely feel that we need both a per-system time zone
  25. and a per-process (or per-user) time zone.  Machines are stationary,
  26. but users are mobile (and sometimes far away).
  27.  
  28. (I imagine that timezone is not in the dictionary because its not a word).
  29.  
  30. [ Is filesystem a word?  -mod ]
  31.  
  32. -- 
  33.  From the virtual mind of Allyn Fratkin            allyn@sdcsvax.ucsd.edu    or
  34.                           UCSD EMU/Pascal Project  {ucbvax, decvax, ihnp4}
  35.                           U.C. San Diego                         !sdcsvax!allyn
  36.  
  37.  "Generally you don't see that kind of behavior in a major appliance."
  38. -- 
  39. Allyn Fratkin                    allyn@sdcsvax.ucsd.edu
  40. UCSD EMU/Pascal Project          or
  41. U.C. San Diego                   {ucbvax, decvax, ihnp4}!sdcsvax!allyn
  42.  
  43. Volume-Number: Volume 5, Number 60
  44.  
  45.