[LEAPSECS] Future time

[Warner Losh]

On Jan 19, 2014, at 9:48 AM, Steve Allen wrote:


> On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:

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

> 

> Do all applications have to care and have consistent implementation

> => of the night shifts which are 7 hours long in spring and 9 in fall?

> => of the change to daylight time that Russia is rumored to be

>   considering to decree after Sochi is over?

> => of the sequence of calendar days in Samoa when it moved itself

>   across the International Date Line?n


They do care, because they use the olson database and that just takes care of it.


> All applications on Mac/iPhone/iPad in Jordan right now that care

> about the time zone are getting it wrong by an hour.  Life in Jordan

> goes on.


The olson database updates will take care of that.


> If the leap seconds were placed into a similarly inconsequential part

> of the interfaces then the applications could be similarly wrong about

> leap seconds yet life would go on.


Correct. That's my point. Nearly all programs use the olson database through libc, and get time as right as they can. Leap seconds aren't in a similar position (despite being in the olson database, they are effectively unused). My point is that this should change, or leap seconds will continue to be a thorn in the side of everybody. It is broken by design...

Warner