[time-nuts] FW: Bulletin C number 30

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Jul 4 15:02:35 EDT 2005


In message <20050704.204026.56945047.cfmd at bredband.net>, Magnus Danielson write
s:
>> >> It also means that the attempt to prevent leapseconds before they
>> >> do more damage failed...
>> >
>> >Would the alternative be much better?
>> 
>> Lets not restart that discussion :-)
>
>I kindly asked for your opinion. I know there have been debates on this, but I
>haven't followed them and whatever solutions I have seen all have downsides
>that I don't think is an improvement. In the end, I think this might be a
>bicycle-stand discussion in which there is no real right answer, we just need
>to select one of them and stick with it for better or worse.

My opinion was rather forth and back, until I read (yet another) article
about colonizing Mars.

It just doesn't make any sense for an astronaut on Mars to adjust
leap-seconds.

And btw, it probably would not even be a leap-second for him, since
general relativity would take its toll.  I'm not sure my grasp of the
math is good enough to figure out how long his leap-second would be.

Instead, if we abandon leap-seconds, then we finally have a _truly_
universal timescale.

It will not be locked to any more or less random piece of geophysics,
anyone with a cesium clock and a set of gen-rel coordinates will be
able to figure out what time it is, and time intervals can be measured
and compared without weird gottchas.

Yet it would still be a good enough approximation for the 99% of
the population to not notice any difference for the next half
millenium and if we find out we want to keep the sun "near south
at noon" we can jump timezones to do so with 100 years of advance
notice.

The other half is that leap-seconds are just not testable in a computer
setting, and therefore I am sure that any cost of dropping them will
be totally offset by the savings in the IT industry.

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.




More information about the time-nuts mailing list