[LEAPSECS] pick your own length of second

[Warner Losh]

On Jan 12, 2012, at 10:13 PM, Dennis Ferguson wrote:

> On 12 Jan, 2012, at 16:42 , Ian Batten wrote:

>> On 12 Jan 2012, at 0232, Dennis Ferguson wrote:

>>> If we had a leap second every other week we'd have gotten so

>>> much real life practice that depending on the code and procedures

>>> to handle the leap wouldn't seem so scary.  

>> 

>> It would mean that everything that relies on interval timing would need to understand leap seconds, however, which currently they (in general) don't.   Other than in very specialised applications, timestamp arithmetic doesn't need to be conscious of leap seconds when they are once every 18 months so so; if they were more frequent (like half-serious proposals to go forward one month and back the next, leaving one out in order to perform a leap of the opposite sign) then much more code would need to be aware of it, and because unlike leap years they're not predictable it would be extremely complex to organise for non-connected devices.

> 

> Your example implies that applications which are unreliable if leap seconds

> occur once a month can somehow become reliable if leap seconds occur once every

> 18 months, but I'm not sure how that works.


Disconnected systems tend to be easier to update on 6 month's notice rather than one month's notice, unless leaps are scheduled out far in advance...


> In any case, however, I avoid problems with interval timing and ambiguous event

> timestamping by using kernels which maintain a second timescale ("uptime") which

> is maintained to be frequency accurate to UTC but phase-continuous, with an

> arbitrary epoch.  Applications which don't care about UTC are written to use

> this instead.  This leaves the clock management software free to do what is

> necessary to bring the nominally UTC-aligned timescale into actual alignment

> with UTC when it discovers that the clock is wrong without effecting interval

> times, something which can be necessary (and sometimes require adjustments

> substantially larger than 1 second) particularly for non-connected (or

> seldom connected, or unreliably connected) devices even without leap seconds.


I use (and have written) such systems too...  The hard part is getting the API right that expects UTC since there's no unambiguous encoding for the leap second.  You have to break some rule to get the job done.

Warner