Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some DNS lookups causing 5xx errors due to leap second bug

cloudflarestatus.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: Some DNS lookups causing 5xx errors due to leap second bug

#81

Post by Fnoord »

hartator wrote: post #9
nullc wrote: post #7

My 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…

Or maybe we just need to code system that handles leap seconds correctly.

Glad TOTP refresh every 30 seconds, and are generally valid for at least 1 minute. One second less wouldn't make a large difference.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#82

Post by Fnoord »

hartator wrote: post #9
nullc wrote: post #7

My 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…

Or maybe we just need to code system that handles leap seconds correctly.

Glad TOTP refresh every 30 seconds, and are generally valid for at least 1 minute. One second less wouldn't make a large difference.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#83

Post by craigvn »

admax88q wrote: post #15
whyileft wrote: post #12

Earlier quoted context omitted.

Or maybe we should start holding project managers accountable for these issues instead of simply basing their performance on deadlines.

Classic Hacker News, it's always the PM or the management at fault, engineers are faultless.

;-) 98% of developers would be clueless to leap second issues. Hell, 50% struggle with leap years.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#84

Post by rspeer »

nshepperd wrote: post #80
rspeer wrote: post #68

Earlier quoted context omitted.

That doesn't seem simpler at all. - UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year. - Converting UTC timestamps to human-readable UTC times is simple modular arithmetic. A beginner in any programming language can do it. Converting TAI to UTC requires a lookup table, and it must be updated after the software is rel…

TAI timestamps can unambiguously refer to times years in the future. You can subtract the TAI timestamp from the current time, set an alarm for that number of seconds and it will actually occur on cue . TAI timestamps don't refer unambiguously to UTC timestamps or calendar dates in the future, because the latter two depend on the variable rotation of the earth and (for zoned times) geopolitical whimsy. I don't see wh…

Think through your proposal to track all times in TAI and then convert them for display. What TAI time do you pick to represent the time that will be displayed as "00:00:00 on January 1, 2020"? Are you going to be okay with it changing to "23:59:58 on December 31, 2019" due to the geopolitical whimsy you mention? What if you just wanted it to represent the day "January 1, 2020"? Do you not use timestamps for anything but exact seconds anymore?

UTC doesn't know how long a second is, and TAI doesn't know how long a day or a year is. But most people need to specify "10 years from now" more often than they need to specify "300 megaseconds from now".

Banning leap seconds would be fine. UTC leap seconds are messy but at least we get by. But updating all time conversion software (instead of just updating authoritative clocks) every time there's a leap second is ludicrous.

It's true that applications should use the proper representation for what they're intended to do. And they do. Most applications use UTC because they describe human-centric events. Astronomers use TAI.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#86

Post by bluejekyll »

nullc wrote: post #7

My 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…

While we're at it, can we get rid of daylight savings time too?

Re: Some DNS lookups causing 5xx errors due to leap second bug

#87

Post by rspeer »

userbinator wrote: post #74
rspeer wrote: post #68

Earlier quoted context omitted.

That doesn't seem simpler at all. - UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year. - Converting UTC timestamps to human-readable UTC times is simple modular arithmetic. A beginner in any programming language can do it. Converting TAI to UTC requires a lookup table, and it must be updated after the software is rel…

"- UTC timestamps can unambiguously refer to times years in the future; TAI timestamps cannot, because it is unknown how many seconds will be in each year." Isn't it the other way around, since TAI has no leap seconds? "What would be simpler would be ending the use of leap seconds for a millennium or so." That effectively means using TAI consistently, which is what software not aware of leap seconds would be doing an…

TAI has no leap seconds, but years, as currently defined, do.

And yes, I'm advocating for changing that definition, and making UTC a constant offset from TAI that works the same as TAI for the foreseeable future.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#88

Post by dingaling »

gamegoblin wrote: post #5

I 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

And alternatively I guessed that big services like Cloudflare, responsible for fronting 2.5 million websites, would have been running a preproduction environment clocked-forward to 2017.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#89

Post by wereHamster »

TazeTSchnitzel wrote: post #71
anderskaseorg wrote: post #65

Earlier quoted context omitted.

Except people want to be able to talk about times years in the future despite not knowing the number of leap seconds that may happen in the intervening time. It is more useful in most fields to talk about an event happening every N years/months/days than an event happening every N seconds. Most people do not want a leap second to shift their scheduled event from 10:00:00 every Monday to 9:59:59 or 10:00:01 in the nam…

> Except people want to be able to talk about times years in the future despite not knowing the number of leap seconds that may happen in the intervening time. Doesn't the (TAI, leap second count) tuple solution work for this? Maybe I misunderstand the purpose, but you could use the leap second count to figure out how many seconds the TAI is off by. But that doesn't matter, because date intervals shouldn't be represe…

You can not represent "Next Monday at 12:00" with a tuple (TAI, leap second count), because you don't know how many leap seconds there should be. Or maybe you know for next Monday, but you definitely don't know for the Monday in a year, as leap seconds are only announced ~6 months in advance.

Re: Some DNS lookups causing 5xx errors due to leap second bug

#90

Post by kondbg »

alexforster wrote: post #17
ckdarby wrote: post #10

Earlier quoted context omitted.

Is this not it? https://github.com/cloudflare/dns

Yeah, and Go doesn't expose a monotonic clocksource in its stdlib[1]. I'd bet that's what this boils down to. [1] https://github.com/golang/go/issues/12914

I'm confused on why a DNS server would need to rely on a monotonic clock for its use cases. Is there a part of DNS that relies on the assumption of synchronized, monotonic time? (Perhaps TTL/expiry of records? But I still don't see why having a non monotonic clock source would harm if CF is using Go timers for expiry)
Post reply on HN