REMINDER: Leap Second

Sun Jan 25 18:15:27 UTC 2015

On 25 Jan 2015 17:29:25 +0000, "John Levine" said:

> It shares with time zones the problem that you cannot tell what
> the UNIX timestamp will be for a particular future time.  If
> you want to have something happen at, say, July 2 2025 at 12:00 UTC
> you can guess what the timstamp for that will be, but if there's
> another leapsecond or two, you'll be wrong.

It shares another problem - that doing calculations across a boundary is
difficult. If you have a recurring timer that pops at 23:58:30 on June 30,
and you want another one in 2 minutes. do you want a timer that the next pop
is at 00:00:30 - or 00:00:29? The operating system can't tell whether the
desired semantic is "as close to every 120 elapsed seconds as possible" or
"as close to the half-minute tick as possible".

And of course doing interval math across several years where you cross multiple
leap seconds is even more problematic - for some corner cases that have an
endppoint nearmidnight, doing a naive "timestamp in seconds +/- 86400 * number
of days" can land you on the wrong *day*, with possibly serious consequences...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20150125/020c18f1/attachment.sig>