On Mon 2008-12-22T14:10:25 +0000, Tony Finch hath writ: > The code to implement this has in fact already been written, 15 or more > years ago, but no-one uses it because it breaks too much stuff.
I am aware of the interesting breakages that happened when zoneinfo files were retroactively modified to be inconsistent with POSIX. Clearly that change cannot be done for past history. That's part of the point of this live javascript page http://www.ucolick.org/~sla/leapsecs/epochtime.html > example, there is a lot of time-handling code in the kernel, and because > it does not link with the tzcode library the proposed architecture doesn't > accommodate its requirements. There's also a lot of code which doesn't use > the C tzcode for time handling, such as the Java runtime. There is a > pervasive assumption in Unix that midnight UT is when t % 86400 == 0. So if the broadcast time scale were to become TI then these operations would be taking place at "atomic day midnight" instead of mean solar day midnight. That's still a legitimate kind of day. Are there actually serious technical problems (kindly ignore bureaucratic ones about conformance with UTC) with that sort of thing? The argument that "atomic time will drift by no more than a few seconds from mean solar during this century has been used by those who want to abandon leaps. In the presence of an internationally approved atomic time scale I think that argument goes both ways. It doesn't hurt anybody if certain technical operations drift a few seconds from civil wall clock time. It has become clear in the ITU process that a change to the nature of the broadcast time scale cannot be decreed with less than a decade of advance notice. That's enough time to fix a lot of software and throw away a lot of hardware. If getting leaps out of the broadcast time scale is the principal and urgent *technical* goal then it might be far quicker to decide to choose "TI" than to hope for the *political* goals involved in getting the ITU to disregard the history and the words of the CGPM when they recommended UTC as a form of mean solar time. Technicians can adapt a lot faster than politicians. -- Steve Allen <s...@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs