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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
