[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

Paul Sheer p at 2038bug.com
Sat Feb 19 18:57:14 EST 2011



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








More information about the LEAPSECS mailing list