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

121–130 of 135 posts

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

#121

Post by wyager »

nshepperd wrote: post #103
wyager wrote: post #29

Earlier quoted context omitted.

> 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

"Does not count leap seconds" has to win some kind of award for misleading terminology. I'd wager it's responsible for a significant portion of leap second bugs due to confusion & misunderstanding about what Unix time is: It sounds like what it means is that Unix time counts the number of real, actual, by-the-clock seconds that have passed since the epoch. That would be logical. But what it actually means is that it…

Shit, you're right. It had me totally fooled.

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

#122

Post by zeta0134 »

pycal wrote: post #118
samrolken wrote: post #40

Earlier quoted context omitted.

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.

The Wikipedia Article here, describing Unix Time, indicates precisely the issue. Unix time does not include leap seconds, which means that when a leap second occurs, the midnight transition to the next year needs to insert additional time. Strictly following the standard thus, the Unix timestamp rolls time backwards by one second over midnight, which is precisely the kind of behavior that breaks systems depending on continuous timestamps: https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

It sounds like in your scenario, you would prefer Unix time to instead include the leap second, so that no rollback or time smearing behavior would need to occur. I believe the reason it does not has to do with simplicity: current systems rely on a day being 86,400 seconds, making each year (regardless of leap days) a multiple of 86,400. Leap seconds break this simple assumption. While it would be simple for a new time formatting system to take leap seconds into account, it is not so simple to go and retrofit all of the existing systems for a new formatting standard, and convince so many different groups of developers to change that much code while also agreeing with one another about the changes.

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

#124

Post by recursive »

wyager wrote: post #23
alexbecker wrote: post #19

Earlier quoted context omitted.

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.

I thought we were pushing the optimality curve toward ever greater volumes of ever buggier code.

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

#125

Post by fapjacks »

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.

Or we could just keep time on DST and stop switching. No reason to give up those nice, long summer evenings.

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

#126

Post by user5994461 »

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.

Let's reframe that: His phone dropped on the new year, when everyone is sending a happy new year message to everyone they know.

No link with leap second till proven.

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

#127

Post by ChuckMcM »

carbocation wrote: post #70
Godel_unicode wrote: post #69

Earlier quoted context omitted.

You do know that stars move, right? And not even all in the same direction or at an easily predictable speed. It's illustrative about how hard time is that you tried to create a new system from scratch, with the express purpose of being future proof for space travel, and it's already broken because the fixed point you chose is not, in fact, fixed. Edit: grammar

I believe that ChuckMcM is making a lighthearted, elaborate reference to Stonehenge. (If not, nevermind!)

It has been interesting to see the responses. And yes it was a not so oblique reference to Stonehenge. :-)

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

#128

Post by jsmeaton »

manarth wrote: post #95
jsmeaton wrote: post #76

Earlier quoted context omitted.

I think this is solved by storing an event date as UTC (since we can't always know how many leap seconds will be required), but when triggering an event, we calculate the UTC from TAI + Leap Seconds. An event in the future isn't necessarily a known number of seconds away, which I think is the point you were trying to make. But the parent comment wasn't suggesting all instances of time should be stored as (tai, leap s…

Sometimes it's best to store a scheduled events as "Event localtime" and "Timezone" (where timezone is a named description - e.g. "Europe/Madrid" - rather than an offset - e.g. "+1:00"). This allows the record to stay consistent, even if there are changes to the local time rules - e.g. leap seconds, daylight savings, timezone offset. Imagine a tech-camp had been planned in Cairo, Egypt, to start on 9am on July 10, 20…

Yup, I'm aware of this and should have mentioned it in my comment. Thanks for the follow up.

As an aside, how often do the tz databases for each language get released? Are they usually responsive to notices 3 days out?

Edit: I went looking into the pytz release for the Cairo example from parent.

Olson Timezone Database:

Release 2016f - 2016-07-05 16:26:51 +0200

https://github.com/stub42/pytz/commit/03a4e9b31dd90f3dace1eb...

Pytz:

Release 2016.6 - 2016-07-13

https://pypi.python.org/pypi/pytz/2016.6

So even if the tz database is up to date, there's no guarantee that various library usages of the tz database will be correct for these kinds of changes. Interesting.

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

#129

Post by synotna »

jsmeaton wrote: post #128
manarth wrote: post #95

Earlier quoted context omitted.

Sometimes it's best to store a scheduled events as "Event localtime" and "Timezone" (where timezone is a named description - e.g. "Europe/Madrid" - rather than an offset - e.g. "+1:00"). This allows the record to stay consistent, even if there are changes to the local time rules - e.g. leap seconds, daylight savings, timezone offset. Imagine a tech-camp had been planned in Cairo, Egypt, to start on 9am on July 10, 20…

Yup, I'm aware of this and should have mentioned it in my comment. Thanks for the follow up. As an aside, how often do the tz databases for each language get released? Are they usually responsive to notices 3 days out? Edit: I went looking into the pytz release for the Cairo example from parent. Olson Timezone Database: Release 2016f - 2016-07-05 16:26:51 +0200 https://github.com/stub42/pytz/commit/03a4e9b31dd90f3dac…

Anything less than 2 weeks is a gamble; I follow the time zone list closely and go out of my way to poke some maintainers of libraries we depend on when something like the Egypt change happens

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

#130

Post by askbjoernhansen »

user5994461 wrote: post #126
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.

Let's reframe that: His phone dropped on the new year, when everyone is sending a happy new year message to everyone they know. No link with leap second till proven.

It wasn't midnight anywhere with CDMA service when the leap second happened.
Post reply on HN