home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v5 / text0053.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.0 KB
  1. Date: Wed, 19 Feb 86 17:58:51 est
  2. From: seismo!cbosgd.ATT.UUCP!mark (Mark Horton)
  3.  
  4. >  Yes, I was aware and worried about both problems.  However, in my
  5. >search of timezones and DST rules worldwide I was not able to find any
  6. >current or past rules that would have violated the assumptions.  Future
  7. >rules are unlikely to break the current conventions for fear of confusing
  8. >everybody (it's bad enough now).
  9.  
  10. You haven't looked hard enough.  Also, the minute you make an assumption,
  11. some congressman or some MP in Britain or Japan or wherever will violate it.
  12.  
  13. >>>Discussion of (1) why Daylight Saving Time should not be constrained
  14. >>>to either 0 or 2 changes per year;
  15.  
  16. There is a thing called "Double Daylight Time" which does exactly that.
  17. I think it happened a few years back in some other country (Canada?)
  18. Surely someone on this list can provide details.
  19.  
  20. >>>and (2) cautioning against a
  21. >>>timezone name that may contain numerals, '+', or '-'.  Both points
  22. >>>emphasized the possibility of future bizarre changes.
  23.  
  24. On the contrary, the notion of giving a time zone a name is an American
  25. notion.  They also have names in Europe and Australia, but my impression
  26. is that in many parts of the world, such as Japan, time zones are named
  27. according to the ISO format +HHMM, e.g. Japan is +0900.
  28.  
  29. I'm afraid the variable TZ is already pretty badly broken - it can't be
  30. used in Newfoundland or Central Australia or Saudi Arabia.  (We do have
  31. sites on Usenet in Newfoundland - as far as I know, they all run 4BSD.)
  32.  
  33. elsie!ado has written some code with a much more flexible structure
  34. (and some additional complexity, which I think is unavoidable.)  I
  35. understand he's going to submit it to this group shortly.  I think
  36. it merits serious consideration.  How much goes into the standard and
  37. how much is left to the implementor isn't clear (e.g. is the format
  38. of the time zone description file part of the standard?) but the code
  39. is intended to be public domain, and it ought to make a good start.
  40.  
  41.     Mark
  42.  
  43. Volume-Number: Volume 5, Number 54
  44.  
  45.