4 ms·

I'd like to hear from other HN readers if their applications would have major issues if they did not deal with leap seconds. Curious the domains in which this i

I'd like to hear from other HN readers if their applications would have major issues if they did not deal with leap seconds. Curious the domains in which this is very important.

oh_sigh 12y ago
You could probably find a number of post mortems by googling around for the last leap second, which was June 30 2012 IIRC.
TheLoneWolfling 12y ago
Well, there was this: https://lkml.org/lkml/2012/7/1/203 https://lkml.org/lkml/2012/7/1/203 It affected pretty much everything running (a recent version of) Linux.
- marcosdumay 12y ago
  That's a bug on code that handles leap second. It's not a bug triggered by losing accuracy by ignoring leap seconds. I'm also very curious about what kind of applications will fail if the kernel simply ignored leap seconds, and let the clock get a second out of sync. A computer does not last for long enough for leap seconds to add to anything. I'm unable to come out with any hypothetical use case where that small difference is relevant, but specialized hardware and software to deal with the issue are not necessary.
onion2k 12y ago
https://github.com/search?q=86400&type=Code&utf8=✓ https://github.com/search?q=86400&type=Code&utf8=✓ A quick search on GitHub finds more than two million examples of people assuming 1 day is 86400 seconds. Every single one of those is a bug. Not a critical one (in most cases), but still an example of code that could fail unexpectedly. In the most basic case, code to fetch a date n days ahead that naively assumes fixed length days will return a date n-1 days ahead instead if it runs at exactly midnight eg date("Y-m-d", mktime()+($days*86400)) will return a date $days-1 in the future if it runs on leap second day. An edge case certainly, but if you're adding millions of records a day something you ought to consider.
- dllthomas 12y ago
  "Every single one of those is a bug." The one place I know I've assumed a day is 86400 seconds I also assumed a month was 30 days and a year 365, because it only needed to be an approximate gauge of how much time had passed, didn't need any relation to actual calendar time, and would be dropping far more precision elsewhere. I think it's incorrect to call that a bug, even a non-critical one.
  - Twirrim 12y ago
    On a related note, you'll find lots of cases where seconds are assumed to be 00-59 instead of 00-60. An understandable, but flawed, assumption, and one the leap second really messes up.
  - onion2k 12y ago
    That's fair. Bug is maybe a bit strong. I'd consider them potential bugs, although with cperciva's comment withstanding even that's probably too strong.
- vacri 12y ago
  No, not every single one of those is a bug. "This cookie lasts a day", "This DNS entry lasts a day", and so forth. These aren't issues that require down-to-the-second accuracy. DNS expires a second early? Oh well, go poll upstream. It would be unusual to see an application that relies on something like a DNS entry being exactly 1 day's worth of seconds. The first page of results in that link are mostly cache timeouts rather than functional definitions.
- cperciva 12y ago
  eg date("Y-m-d", mktime()+($days * 86400)) will return a date $days-1 in the future if it runs on leap second day. No it won't. Those functions deal in UNIX-epoch times, which ignore leap seconds.

I'd like to hear from other HN readers if their applications would have major issues if they did not deal with leap seconds. Curious the domains in which this is very important.

oh_sigh 12y ago

You could probably find a number of post mortems by googling around for the last leap second, which was June 30 2012 IIRC.

TheLoneWolfling 12y ago

Well, there was this: https://lkml.org/lkml/2012/7/1/203 https://lkml.org/lkml/2012/7/1/203 It affected pretty much everything running (a recent version of) Linux.

marcosdumay 12y ago
That's a bug on code that handles leap second. It's not a bug triggered by losing accuracy by ignoring leap seconds. I'm also very curious about what kind of applications will fail if the kernel simply ignored leap seconds, and let the clock get a second out of sync. A computer does not last for long enough for leap seconds to add to anything. I'm unable to come out with any hypothetical use case where that small difference is relevant, but specialized hardware and software to deal with the issue are not necessary.

onion2k 12y ago

https://github.com/search?q=86400&type=Code&utf8=✓ https://github.com/search?q=86400&type=Code&utf8=✓ A quick search on GitHub finds more than two million examples of people assuming 1 day is 86400 seconds. Every single one of those is a bug. Not a critical one (in most cases), but still an example of code that could fail unexpectedly. In the most basic case, code to fetch a date n days ahead that naively assumes fixed length days will return a date n-1 days ahead instead if it runs at exactly midnight eg date("Y-m-d", mktime()+($days*86400)) will return a date $days-1 in the future if it runs on leap second day. An edge case certainly, but if you're adding millions of records a day something you ought to consider.

dllthomas 12y ago
"Every single one of those is a bug." The one place I know I've assumed a day is 86400 seconds I also assumed a month was 30 days and a year 365, because it only needed to be an approximate gauge of how much time had passed, didn't need any relation to actual calendar time, and would be dropping far more precision elsewhere. I think it's incorrect to call that a bug, even a non-critical one.
- Twirrim 12y ago
  On a related note, you'll find lots of cases where seconds are assumed to be 00-59 instead of 00-60. An understandable, but flawed, assumption, and one the leap second really messes up.
- onion2k 12y ago
  That's fair. Bug is maybe a bit strong. I'd consider them potential bugs, although with cperciva's comment withstanding even that's probably too strong.
vacri 12y ago
No, not every single one of those is a bug. "This cookie lasts a day", "This DNS entry lasts a day", and so forth. These aren't issues that require down-to-the-second accuracy. DNS expires a second early? Oh well, go poll upstream. It would be unusual to see an application that relies on something like a DNS entry being exactly 1 day's worth of seconds. The first page of results in that link are mostly cache timeouts rather than functional definitions.
cperciva 12y ago
eg date("Y-m-d", mktime()+($days * 86400)) will return a date $days-1 in the future if it runs on leap second day. No it won't. Those functions deal in UNIX-epoch times, which ignore leap seconds.