In message <20060109100127.GI36385_at_finch-staff-1.thus.net>, "Clive D.W. Feather" writes:
>The real problem is not the 23:59:60, it's *predicting* when they happen.
I agree, the short prediction horizon is the major problem.
But 23:59:60 _is_ a problem too.
I don't think anybody dare even think about redefining POSIX time_t
and even if they did redefine it to contain leap-seconds, many tons
of software wouldn't be updated/recompiled to take advantage of it.
So the standards crew, POSIX, LSB or whoever would have to come up
with a new data type for holding timestamps, and while a number of
proposals have been floated over the years, none of them seem to
contain any real clue, so I don't think this is likely to happen.
But pressume for a moment that they did come up with a new standard,
the many tons of software would still not be rewritten to take
advantage of it, so we'd still be stuck with time_t's ostrich
behaviour for the forseeable future.
Unlikely as it is, it would allow people like Warner and me to write
software that Do The Right Thing.
A far more sensible idea is to just forget about leap-seconds from
now on, leave DUT1 to wander, tell BIPM/IERS to provide a contemporary
kind of service (internet services instead of handwritten letters),
the astronomers to shut up&cope and leaving the issue of the length
of day in 500 years to the people who live 500 years from now on.
It's the comparison between educating all programmers in the world
vs having the astronomers use a DUT which is larger than 1 second.
There is no doubt that from a humanistic point of view it would be
better to educate all the programmers, but considering that I still
suffer from web-forms that insist I enter a USA style phone number
when I have entered "Denmark" as country, this is a far moure
daunting task than it might appear.
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.
Received on Mon Jan 09 2006 - 02:32:30 PST