[LEAPSECS] Crunching Bulletin B numbers (POSIX time)
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
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.
More information about the LEAPSECS