[LEAPSECS] The relation between calendars and leap seconds.

[Poul-Henning Kamp]

In message <86269.1226445135 at critter.freebsd.dk>, "Poul-Henning Kamp" writes:



>But more importantly, they put their lives, unaware of this fact,

>in hands of automatic systems, which work on the mistaken POSIX

>interpretation of the UTC timescale.


I should add, that the legal impact of POSIX seems to be vastly
underestimated by the astronomers in this forum, so let me
explain how deeply this cuts.

For our purposes, the paper trail starts with the C-language (STD-C)

	International Standard ISO/IEC 9899
	Programming Languages -- C

which defines the time_t data type pretty loosely, and with certain
auxillary time conversion functions of which some offer support
for handling leap-seconds, provided you know what the leap second
count is for the time you are trying to deal with.

Then comes:

	International Standard ISO/IEC 9945-1:1990
	Information Technology
	- Portable Operating System Interface (POSIX) 

which imports STD-C and in section 4.14 codifies the troublesome
stupidity:

	4.14 Seconds Since the Epoch
	[...]
	As represented in seconds since the Epoch, each and every
	day shall be accounted for by exactly 86400 seconds.

This is not as much an active choice of the standardization body,
as it is a codification of widespread and existing practice, which
they dared not change, should they even have wanted to.

For full details on this tragedy, see chongos excellent saga here:

http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html

The full scale of the scientific ignorance employed is indicated
from this horror:

	 2) We defined the epoch as "1970 Jan 1, 00:00:00 UTC".

	       This was defeated and UTC was replaced with GMT.

(The fact that ISO cannot find their ass with a flashlight when it
comes to IT related standards, have been so amply demonstrated
by POSIX, that the OOXML debacle shouldn't surprise anybody.)

Then, examining USA as an example, NIST comes in:

	FIPS-151-2
	Portable Operating System Interface (POSIX) -
	System Application Program Interface [C Language]

Which adopts POSIX, and makes it a requirement for pretty much all
federal, and in particular the lucrative DoD and DoE, IT investments.

The success of this push for standardization can be seen from the
fact that all currently viable operatingsystems, from Windows to
IBM's MVS sport a POSIX facility, see for instance:

Microsoft:
	http://technet.microsoft.com/en-us/library/cc768080.aspx

IBM:
	http://www-01.ibm.com/cgi-bin/common/ssi/ssialias?infotype=an&subtype=ca&htmlfid=897/ENUS294-152&appname=isource&language=enus

Whereas the non-POSIX compliant operating systems, such as VMS, AOS
and their ilk, have all gone to rest peacefully at
http://bitsavers.trailing-edge.com/


And there you have it: by the sheer effort of scientific incompetence,
all federal and defense systems acquired in the last decade has
been very very careful to screw up leap second handling, precisely
as to specified in POSIX.

The situation everywhere else in the world is exactly the same,
with more or less awareness of there even being an issue.

The only change to leap seconds we can come up with, that does not
require all of this to be treated to a Y2K style audit, is to
stop sticking leap seconds in UTC and live with it.

And even if we do get political acceptance of such a revision,
we have still not solved the issue with dissemination of leap
second warnings with short (ie: less than 10 years) notice.


Any technical or practical problems with telescopes which the
astronomers might encounter due to lack of leap seconds in UTC
will cost less than the feasibility study NIST will have to
do on the regulatory change.

The true cost of the change would be staggeringly unknownable.

Poul-henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.