[LEAPSECS] Future time

[Warner Losh]

On Jan 18, 2014, at 10:16 PM, Tom Van Baak wrote:


>> The problem is that all applications should care about leap seconds.

>> It is a part of the time standard (UTC) that is papered over in POSIX time_t.

>> This is a false partitioning, and what causes the probelms.

> 

> Warner,

> 

> "All" applications should care? It's that going a bit too far? What, are you going to ban every analog clock? Fahrenheit 86400?


All applications should care. Otherwise, it isn't a universal time standard and becomes a non-standard footnote. All applications should get leap seconds right, even if they delegate that to a library that handles the details.


> UTC is simple and clearly defined and we all know the ideal/right way to handle that time scale, and by arithmetic offset, any local time. But there is also the matter of precision: different applications are looking for different levels of UTC precision. The often unstated precision requirement makes a big difference.


All applications should be able to cope with leap seconds when present, or when absent.


> Where you get UTC from and how you store or display UTC are dependent on the type of application. Applications needing 1 ns precision must use a UTC(k) with circular-T, UTCr, or other real-time or post processing corrections applied. Applications needing only 1 us or 100 ns precision can get UTC via cheap GPS receivers. Applications needing 1 ms precision can use NTP. Those that need only 2 s or worse precision can get away with ignoring leap seconds, if they choose, because the resulting time-stamps are still well within the specification.


"get away with" is part of the problem. It means UTC truly isn't universally adapted. It needs to be, or leap seconds will continue to be a thorn in the side of things. Applications "ignore" them because they are hard or require extra effort. They don't ignore them because they don't want them and are rejecting leap seconds. They ignore them because they want to hit the easy button. My point is that they should be able to ignore these details of leap seconds much like they ignore dates and such. There's good libraries and APIs that make it possible to pretty much ignore all the details about dates and knowing that March has 30 days. No such libraries are in wide spread use, and time_t militates against its creation in many ways.

That's what I mean by "all" applications (computer applications) should care. Otherwise we get the two-tier system we have now where leap seconds are such second class citizens applications wanting to get them right have to jump through lots of hoops (doing their own time stuff), or they have to sacrifice some aspect of time to make things work: Give up on monotonically increasing time_t, give up on actually doing leap seconds (by smearing ala Google), etc.

Warner