I was at a relative's and tried to load two different web sites.. my first thought was that their wifi sucked. My second was "will we finally learn a lesson today about the disturbing trend towards constant re-centralization of all our online services?"
Some DNS lookups causing 5xx errors due to leap second bug
21–30 of 135 posts
Re: Some DNS lookups causing 5xx errors due to leap second bug
#22My CDMA phone dropped service for a few minutes after the leap second. It's absurd that we continue to keep subjecting ourselves to these disruptions and the considerable amount of work that goes into handling leap seconds for the systems that aren't disrupted by them. Leap seconds serve no useful purpose. Applications that care about solar time care usually care about the local solar time, while UT1 is a 'mean solar…
But is it a bug or network saturation under people wishing each others a happy new year? (And Perhaps more so with a selfie than a text msg as prev yrs)
[deleted]
Re: Some DNS lookups causing 5xx errors due to leap second bug
#23Earlier quoted context omitted.
Or maybe we just need to code system that handles leap seconds correctly.
Maybe we should code systems with zero bugs. /s
Well, yeah, that's not a bad idea. It was kind of Dijkstra's whole thing. The problem is that, at current levels of technology, it's economically better to write cheap buggy software than more expensive bug-free software for almost all consumer applications. We are gradually pushing the optimality curve towards the provably bug-free end of the spectrum, but it will take time.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#24I guessed most big services would be using something akin to time smearing [1] since the first big leap-second outages years ago. Is there any reason why cloudfare would be unable to use this technique? [1] https://developers.google.com/time/smear
It's pretty lame that a lot of software is so fragile that it breaks if we give it the correct time.
The solution here is that any software that relies on accurate timing and/or breaks when you change the time should be using epoch seconds, not any sort of human-oriented time format.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#25Earlier quoted context omitted.
Or maybe we just need to code system that handles leap seconds correctly.
Two valid points. A third: convince everyone to adopt epoch time for data transfer (seconds since epoch), and let applications that require formatted time do the transformation where it will be used (not earlier). It doesn't make a lot of sense that a timestamp represented as HOUR/MIN/SEC:DAY/YEAR should be passed around on the network of a production system. Leave it to the recipient to convert. I guess this is a su…
Leap seconds aren't just an issue of formatting times. Leap seconds actually involve turning the UTC count of seconds back by a second.
You'd have to switch the "seconds since epoch" count to TAI, and that would cause new formatting bugs because all kinds of software assumes that the minute changes on a multiple of 60 seconds since the epoch.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#26I guessed most big services would be using something akin to time smearing [1] since the first big leap-second outages years ago. Is there any reason why cloudfare would be unable to use this technique? [1] https://developers.google.com/time/smear
It's pretty lame that a lot of software is so fragile that it breaks if we give it the correct time. The solution here is that any software that relies on accurate timing and/or breaks when you change the time should be using epoch seconds, not any sort of human-oriented time format.
Leap seconds are a change to the number of UTC epoch seconds.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#27I'm curious what if anything would be problematic if everything just effectively "ignored" leap seconds (i.e. would this outage not have occurred?) --- one minute is always 60 seconds, an hour is always 60 minutes, and a day always 24h. I mean, if you consider the fact that human society has managed to function perfectly well with almost everyone not knowing nor caring what a leap second is, and yet apparently some s…
Financial systems need very precise timekeeping. I'm sure other fields do as well.
They do, and actually HFT did come to mind when I was writing that comment, but then I realised that, as explained in https://news.ycombinator.com/item?id=13294747 , they have no need to precisely synchronise time with the rotation of the Earth, and would be fine without leap seconds.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#28I'm curious what if anything would be problematic if everything just effectively "ignored" leap seconds (i.e. would this outage not have occurred?) --- one minute is always 60 seconds, an hour is always 60 minutes, and a day always 24h. I mean, if you consider the fact that human society has managed to function perfectly well with almost everyone not knowing nor caring what a leap second is, and yet apparently some s…
Financial systems need very precise timekeeping. I'm sure other fields do as well.
But financial systems don't care if the position of the sun in the sky is a couple of seconds off from where a model says it should be. Astronomers would care about that, but they already don't use UTC.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#29Earlier quoted context omitted.
It's pretty lame that a lot of software is so fragile that it breaks if we give it the correct time. The solution here is that any software that relies on accurate timing and/or breaks when you change the time should be using epoch seconds, not any sort of human-oriented time format.
Leap seconds are a change to the number of UTC epoch seconds.
> Leap seconds are a change to the number of UTC epoch seconds.
UTC is different from epoch time. Epoch time by definition does not count leap seconds. https://en.m.wikipedia.org/wiki/Unix_time
Re: Some DNS lookups causing 5xx errors due to leap second bug
#30My CDMA phone dropped service for a few minutes after the leap second. It's absurd that we continue to keep subjecting ourselves to these disruptions and the considerable amount of work that goes into handling leap seconds for the systems that aren't disrupted by them. Leap seconds serve no useful purpose. Applications that care about solar time care usually care about the local solar time, while UT1 is a 'mean solar…
But is it a bug or network saturation under people wishing each others a happy new year? (And Perhaps more so with a selfie than a text msg as prev yrs)
Given that it's cdma, moat likely the user was in the US or thereabouts, so the leap second was several hours before local new year.