[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

[Paul Sheer]

On Sat, 2011-02-19 at 23:25 +0000, Ian Batten wrote:

> >

> > to do this correctly for ten years, it would need a ten year leap

> > second table.

> 

> Or someone to supply a manual update every two or three years.  If the  

> machine is so isolated that it cannot receive those updates, why does  

> the high-precision timestamp in the logs matter?  This is what I fail  

> to see: systems which are so isolated from timekeeping hat they cannot  

> receive one-bit updates, and yet are so tied into timekeeping that  

> they need to generate and store timestamps to high precision.  What's  

> the use case?  Not some hypothetical, but a real application?

> 



It is not only about being soooo isolated, but also about not being
able to download the leap second table for any reason whatsoever.

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.

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.

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.


In a different discussion, whatever API we finally decide upon will
have to be able to deal with BOTH leap-second-inclusive AND broken-posix
timestamps so that authors are able to write applications that can
handle both timestamps. This will allow a migration path.

-paul