[LEAPSECS] Future time

[Joseph Gwinn]

On Sat, 18 Jan 2014 19:51:33 -0700, Warner Losh wrote:

> 

> On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:

>> 

>>  Those applications which do care about leap seconds can determine

>>  how to handle them in whatever way those applications feel is

>>  best.

> 

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


There are applications where the timescale cannot have any step 
discontinuities.  Like airplane and missile guidance.

 

>> I think today this would require including a leap second table

>> yourself.  I do know for sure that my gettimeofday() returns

>> a seconds-since-the-epoch that includes leap seconds, so, without

>> Olson right/, i'm afraid the timestamps are wrong.

> 

> This turns out to be difficult to arrange if you have to know time 

> early in your startup sequence. GPS receivers can give it to you, 

> unless they are a 'cold spare' that have been turned off for more 

> than 6 months, then you have a time jump if there's been a leap 

> second in the interim (because cached values become wrong)...  Or you 

> have a delay until the number is known after the almanac is 

> downloaded. It is this problem that's lead me and others to suggest a 

> longer time horizon for leap seconds to ensure that the use cases are 

> more easily handled.

> 

> Of course, the 6 month window does make it impossible to compute a 

> time_t for a known interval into the future that's longer than 6 

> months away...


And there is always the problem that one really really hopes that the 
guidance still works after an unpredicted leap.

So, one creates a TAI-like timescale.  This also simplifies the 
software, as only a few human-facing applications need to care about 
leap seconds, and if these few applications stumble, it's only an 
annoyance.

Joe Gwinn