[LEAPSECS] Standards of time zones -Brooks Harris

Hal Murray hmurray at megapathdsl.net
Fri Jan 10 00:57:49 EST 2014



(from a day or two ago...)

Brooks Harris <brooks at edlmax.com> said:

> So I ask your opinion(s) - Do you think there's a need for a document like

> I've described? What standards body do you think would be receptive to the

> idea? Or is it a fool's errand?


If I was going to try to fix that, I think I would start by talking to the OS
and POSIX people. I don't know if they would be receptive. Even if they
were, it might still be a dead end, but then I would (might?) learn something.

The fundamental problem with POSIX timekeeping is that it pretends that leap seconds don't exist.

What would you like for an API if you were starting over and wanted to support leap seconds? What would you have to change in the OS and libraries?

There now exists lots and lots of software that uses the no-leap approach, and zillions of disks full of old/POSIX time stamps. We will never "fix" all of that, so we will be stuck supporting the old API forever.

If the OS keeps time in TAI, then some combination of the OS and libraries needs to know when the leap seconds have and will happen.

A common criticism of keeping time in TAI is that leap seconds are not predictable so it's hard to build embedded systems that will keep working in local time past the latest leap-second announcement. We should be able to tweak NTP to distribute a table of leap seconds. (Eventually, the table will overflow a UDP packet size. :)

Are there any interesting systems where time is important but they don't have internet connections? How do they set their clocks?

---------

In 2038, the 32 bit time-stamp wraps around into negative numbers. Maybe all 64 bit time stamps should be in TAI rather than UTC.



--
These are my opinions. I hate spam.





More information about the LEAPSECS mailing list