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. > 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... Warner _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
