[LEAPSECS] Standards of time zones -Brooks Harris

[Warner Losh]

On Jan 9, 2014, at 10:57 PM, Hal Murray wrote:


> 

> (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.


In the past, the POSIX committee has been down right hostile to fixing this issue, which they view as a non-issue since it is just a second anyway... It took years to get the double leap second issue fixed.


> 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.  :)


This works well for connected systems, but many of these embedded systems don't necessarily have a connection to the world. GPS is used to feed them time, but that won't allow them to sit on the shelf for 9 months and still have the right count and timing of leap seconds.


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


LORAN-C. The timing systems for these systems didn't have an internet connection (thought they were networked). They got their time from GPS and recovered UTC from that. In these systems, you could have a 1 second error or more for historic time stamps. They also imposed weird startup requirements that meant these systems couldn't start until the new almanac is downloaded.

Though I guess that LORAN-C has been shut down, but it is where I developed my futilitarian attitudes about systems ever implementing leap seconds correctly.


> 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.


time_t isn't proscribed to be 32-bits, and many systems today have moved to 64-bit time_t.

Warner