In message <52cc8c26.5090...@edlmax.com>, Brooks Harris writes: >I fully understand time zone specifications are fractured. My objective >is to determine what standards are most relevant currently, that is, >what standards may be considered "in force". And where none exist, to >state some sort of rules of "common use" or "common practice" without >referring to the impossibly large collection of local jurisdictions and >laws.
There is no way to do that, because timezones are purely a matter under the jurisdiction of national or in some cases even provincial governments, and they are free to do any damn thing they want to them. Various governments have repeatedly made sure this fact is not overlooked. >A) "International Date Line", which is probably not standardized [...] It is not. In only exists as a the result of local governments deciding what timezones to use. Some Pacific Island nation "jumped" timezones for Y2K in order to be the first country to "arrive in the new millenia. The "intenational date line" is simply where you, in broad daylight, have a country with one date on one side and another country with a different date on the other side. >B) The "International Meridian Conference of 1884" contains significant >discussion of the idea "That these standard meridians should continue to >be designated as even multiples of fifteen degrees from Greenwich", but >there appears to be no explicit resolution of vote on the topic. And there were none subsequently. Strict 15 degree meridians would be very impractical, unless national borders were aligned with them. Despite significant attempts at map-redrawing in the first half of the 19-hundredes, timezones were never a reason for it. UTC was standardized so that telephone, telegraph and radio operators would not have to keep track of local politics all over the world in order to operate. In practice, the "olsen" database is a post-facto recording of political whims with respect to timezones. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs