[LEAPSECS] any other parties?

Warner Losh imp at bsdimp.com
Mon Jul 9 12:00:32 EDT 2012

On Jul 9, 2012, at 9:30 AM, Rob Seaman wrote:

> On Jul 9, 2012, at 8:13 AM, Warner Losh wrote:


>> Except that isn't POSIX time_t compliant, alas. That's the other variation I forgot, which is to use the "right" timezone files, which also have their own set of problems for long-running applications (a variation on getting the UTC leap second tables problem). I've gone on at length in other forums why this is clever, but not a complete solution.


> Why not share with this forum? If it is incomplete, why not focus on what work remains to be completed?

Well there's two fatal flaws in the current implementation. One is a design flaw. The POSIX time_t requires that midnigh be = modulus 86400. These break that invariant. The second is an implementation detail: once your program starts, changes to the zone files are never noticed, so no new leap seconds can be recorded. This leads to time skew in long-running programs as leap seconds accumulate. Also, the zone files have to be updated every 18 months.

>> Also, a never ending stream of TAI seconds is easy to count, but hard to convert to UTC since you need a leap second table to do that. This can present problems to applications that need to present a UTC time to the outside world that have been off for a while. GPS can give you the current TAI time very quickly, but cannot give you the UTC time until it has downloaded the almanac (especially if the device has been off > 6 months).


> Not entirely clear why we should limit ourselves to considering prior (and demonstrably wrong) software and engineering standards, protocols, and infrastructure as sacrosanct, while simultaneously pursuing a redefinition of UTC and complete undermining (failure guaranteed) of the meaning of "day" and "universal time".

The problem is that the notion of time without leap seconds is totally engrained in the software that's written because the standards there don't recognize leap seconds as something worth standardizing. This leads to everybody getting something wrong, by definition.

> For one thing, implementing new systems is more fun :-)

Sure. Good luck getting it adapted.


More information about the LEAPSECS mailing list