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

111–120 of 135 posts

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

#111

Post by JshWright »

toomanybeersies wrote: post #104
bluejekyll wrote: post #86

Earlier quoted context omitted.

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

As a programmer, I hate daylight savings, but asa human being, I love daylight savings. It's just so nice to get that extra bit of sunlight in the evening.

As a human being, I hate daylight saving time... It's very disruptive to sleep schedules (particularly for children, but adults as well). Traffic accidents spike in the days after the DST switch (likely due in part to the aforementioned sleep disruptions). Summer days are plenty long already...

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

#112

Post by XorNot »

userbinator wrote: post #61
XorNot wrote: post #42

Earlier quoted context omitted.

But they do care what GPS reference time is. Which are satellites very much dependent on holding an accurate position in the sky (which is dependent on the Earth's rotational speed, which changes, which is why we have leap seconds). So go figure: which part of this system should be broken because people keep ignoring that leap seconds happen?

Actually, GPS time is not adjusted for leap seconds: http://tycho.usno.navy.mil/leapsec.html

That's neither here nor there: GPS receivers, and the GPS satellites, do broadcast the leap-second insertions (though they don't reset their own clocks, they simply maintain the differential as additional information).

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

#114

Post by Philip_with1L »

JshWright wrote: post #111
toomanybeersies wrote: post #104

Earlier quoted context omitted.

As a programmer, I hate daylight savings, but asa human being, I love daylight savings. It's just so nice to get that extra bit of sunlight in the evening.

As a human being, I hate daylight saving time... It's very disruptive to sleep schedules (particularly for children, but adults as well). Traffic accidents spike in the days after the DST switch (likely due in part to the aforementioned sleep disruptions). Summer days are plenty long already...

Yes, exactly my thoughts. While it's great that automated systems and networks can account for this man-made invention of time change, it is very stressful on humans and also unnecessary. A dissolving and averaging out to a new standard would help everyone out in the long run..

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

#115

Post by tyingq »

kondbg wrote: post #90
alexforster wrote: post #17

Earlier quoted context omitted.

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)

One example might be rate limiting. Count requests over elapsed time. If elapsed time is a negative number, the math might trigger a bug that causes CF to block requests...too many requests over time period X.

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

#116

Post by cmdrfred »

perennate wrote: post #53
ChuckMcM wrote: post #47

Once again we're screwed by different people wanting "time" to mean different things. There is no hope for humanity once we start traveling anywhere close to light speed into and out of the solar system. I propose a new "non-time" time system. It has exactly two real values which range from 0 to tau and an integer, the first real number is radians of earth rotation, and the second is radians of the rotation around th…

If we somehow manage to "reverse" the Earth's orbit around the sun, does that mean we will have invented a time machine?!

I'd be more impressed with a machine that can decelerate the earth and reverse it's spin direction without killing everyone as opposed to a time machine personally.

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

#117

Post by kevin_nisbet »

imglorp wrote: post #108
yuubi wrote: post #67

Earlier quoted context omitted.

CDMA system time is already defined as free of leap seconds. --- 3GPP2 C.S0002-A section 1.3 "CDMA System Time": All base station digital transmissions are referenced to a common CDMA system-wide time scale that uses the Global Positioning System (GPS) time scale, which is traceable to, and synchronous with, Universal Coordinated Time (UTC). GPS and UTC differ by an integer number of seconds, specifically the number…

But yet, parent poster's phone dropped, so that migration from UTC=GPS+N to UTC=GPS+N+1 would result in the same conniptions we all have to deal with an extra second in the day. Even if it is at the phone's presentation layer, that's several GB of software that might hold lurking N+1 bugs causing the data layer to drop.

Agreed, while the CDMA specification requires tight time syncing, like everything else the UNIX OSs used to run the equipment can receive the leap indicator. Any problem within the OS, or the software reading date/time from the OS can cause instability.

Also, without knowing more about what exactly went wrong with your phone, it's possible other infrastructure within the network was unstable, signalling equipment, etc. I can't remember exactly, but I think some of the CDMA equipment at my previous company had a leap second problem previously. And the equipment is no longer being maintained or patched really.

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

#118

Post by pycal »

samrolken wrote: post #40
lend000 wrote: post #36

Earlier quoted context omitted.

Yes but even here, seconds since Epoch should remain unaltered, and the correction should be made by whatever is rendering a human readable date format (to address every leap second). In most cases, the renderer wouldn't have to address it (since it's only being read by humans, and a second difference does not usually matter) and it's truly a non-issue! The application-layer dev can choose to increment time in whatev…

Unfortunately, epoch time is not literally "seconds since epoch", at least not as implemented/standardized as "Unix time". It skips or repeats itself in case of leap seconds. So it can't save us here. I think if there were such a thing as a different kind of epoch time that literally actually is "seconds since epoch" it would help a lot and work like you suggest.

Is this correct? Because I am having trouble understanding the rationale behind making the unix epoch relative to an earth solar year, as opposed to just the "number of seconds which have elapsed since the unix epoch". Do you have an example of this implementation? The Wikipedia article regarding epoch notes many counter-examples.

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

#119

Post by beering »

wereHamster wrote: post #89
TazeTSchnitzel wrote: post #71

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. 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.

I think you cannot represent "Monday in a year at 12:00" with a simple integer either, right? For example, the king of the country may decide to cancel DST for the year. Either way you would have to store it as a calendar event and figure out the exact time once you're closer.

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

#120

Post by imglorp »

kevin_nisbet wrote: post #117
imglorp wrote: post #108

Earlier quoted context omitted.

But yet, parent poster's phone dropped, so that migration from UTC=GPS+N to UTC=GPS+N+1 would result in the same conniptions we all have to deal with an extra second in the day. Even if it is at the phone's presentation layer, that's several GB of software that might hold lurking N+1 bugs causing the data layer to drop.

Agreed, while the CDMA specification requires tight time syncing, like everything else the UNIX OSs used to run the equipment can receive the leap indicator. Any problem within the OS, or the software reading date/time from the OS can cause instability. Also, without knowing more about what exactly went wrong with your phone, it's possible other infrastructure within the network was unstable, signalling equipment, et…

Past life $work made UTDOA equipment for GSM networks. The hardware used a number of GPS modules from various vendors to obtain GPS time, which someone noted above includes leap offset broadcast in the periodic almanac.

Anyway, of three different module vendors, two got leap handling wrong. Then our own code had its own leap bugs, on top of the OS (Solaris) timekeeping bugs such as clock jumps and timezone update issues. Good times.

Post reply on HN