[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

[Ian Batten]

On 19 Feb 2011, at 23:57, Paul Sheer wrote:

> 

> It is not only about being soooo isolated, but also about not being

> able to download the leap second table for any reason whatsoever.


Suppose the leapseconds were guaranteed to be announced 12 months in advance.  Anything that can't perform an update, either manually or automatically, for that period but which also expects to maintain a clock to a precision better than 1s/18mo is hard to imagine.  Do you have a case in mind?


> 

> The conversion from 1298159105 to and from "2011-02-19 23:45:05" on

> Posix is currently not inclusive of leap seconds: you just do division

> by 86400.

> 


And you can do that without leapseconds to a precision of 1s/18mo, which aside from bizarre fantasies of machines hooked to Caesium/Rubidium clocks but unable to perform one bit/18mo of I/O to the outside world is better than the precision of the clocks anyway.


> A proper api includes leap seconds. hence the conversion depends on

> what's in your leap second table. "2011-02-19 23:45:05" is really

> 1298159129 in the Olson library.

> 


So what?  If you ignore leap seconds in your isolated/cut-off example, one consequence will be that an increasing window of seconds immediately before midnight UTC will be "wrongly" reported as being in the following day, because the local clock will have gained against UTC.  But so what?  It'll report 00:00:03 Monday when it's "really" 23:59:57 Sunday --- why is this small number of seconds any more important than any other small number of seconds error?  I'm still not grasping the use-case for a precision clock that doesn't do I/O with the outside world.



> The unix world is replete with software that converts both to and

> from ascii timestamps.

> 

> for example, the conversion function should *behave* *consistently*

> regardless of your network suddenly becoming unplugged and your not

> being able to get the latest leap second table.


It can't do that and also tick any timescale which is related to solar time.   

ian