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

61–70 of 135 posts

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

#61

Post by userbinator »

XorNot wrote: post #42
rspeer wrote: post #28

Earlier quoted context omitted.

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.

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

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

#62

Post by EGreg »

perennate wrote: post #55
EGreg wrote: post #54

Earlier quoted context omitted.

Is it safe to say that time() in php and Date.now() in JS do not care about leap seconds?

From [1], it is likely messier than that: > The time() function will resolve to the system time of that server. If the server is running an NTP daemon then it will be leap second aware and adjust accordingly. PHP has no knowledge of this, but the system does. > It took me a long time to understand this, but what happens is that the timestamp increases during the leap second, and when the leap second is over, the time…

It would seem much simpler to just use TAI for timestamps, and get civil datetimes from UTC. Why didn't people do this? Why use UTC for timestamps??

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

#63

Post by greglindahl »

mark-r wrote: post #43
hartator wrote: post #9

Earlier quoted context omitted.

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

It's difficult to write bug-free code for events that happen very infrequently. Even more so when the distributed nature of the system makes effective testing under real-world conditions nearly impossible.

Yeah, that's exactly why Leap Day getting skipped every 4th year is such a disaster.

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

#64

Post by tezza »

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…

and if the earth speeds up or slows down we loose sync with far off time keepers who dont know yet ?

mostly this is tektonic re-adjustments on a minor level or asteroid strike on a major level. of course you could say that an asteroid strike would be a larger problem than re-syncing the stone clock

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

#65

Post by anderskaseorg »

zkms wrote: post #49

What causes real-world problems with leap seconds is actually unrelated to the nasty interactions of metrology and solar time -- it's a specific and avoidable problem with how NTP (and many OSes/languages) represent time -- it's a types issue. The right way for computers to represent time is with a number that represents the number of constant-rate ticks that have elapsed past a some agreed-upon epoch. If you know wh…

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 name of using a whole number of 86400-second intervals.

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

#66

Post by rz2k »

DigitalJack wrote: post #41
userbinator wrote: post #8

I'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…

100 seconds per minute, 100 minutes per hour, 20 hours a day. New seconds are 0.432 old seconds, or whatever ratio they need to make to quit leaping around.

The metric system is a great system because it is almost universal. Base 10, as well as the other choices for what is ideal might be argued as inferior to other measurement systems.

Since the time we are talking about is going to be used by computers it might as well be base 2.

64 seconds per minute, 64 minutes per hour, 36 hours per day. You could then choose 8 days a week, 32 days per month, and 11 months (44 weeks) per year followed by 4.24... days of festivals to the pagan gods.

Just like before, the problem is that there are exogenous values: a non-constant length of year at an Earth location, a non-constant length of day at an Earth location, and a more constant period of time defined by a lower level process of nature like caesium atom vibrations for the seconds that scientists use.

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

#67

Post by yuubi »

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…

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 of leap second corrections added to UTC since January 6, 1980. The start of CDMA System Time is January 6, 1980 00:00:00 UTC, which coincides with the start of GPS time.

System Time keeps track of leap second corrections to UTC but does not use these corrections for physical adjustments to the System Time clocks.

---

I'm pretty sure the only use of leap seconds in CDMA is for converting system time to customary local time, along with the daylight-time indicator and time-zone offset also contained in the sync channel message.

Edit: C.S0005-E section 2.6.1.3 says the mobile station shall store most of the fields of the sync channel message; it may store leap second count, local time offset, and daylight time indicator. This suggests that these fields aren't really that important for talking CDMA.

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

#68

Post by rspeer »

EGreg wrote: post #62
perennate wrote: post #55

Earlier quoted context omitted.

From [1], it is likely messier than that: > The time() function will resolve to the system time of that server. If the server is running an NTP daemon then it will be leap second aware and adjust accordingly. PHP has no knowledge of this, but the system does. > It took me a long time to understand this, but what happens is that the timestamp increases during the leap second, and when the leap second is over, the time…

It would seem much simpler to just use TAI for timestamps, and get civil datetimes from UTC. Why didn't people do this? Why use UTC for timestamps??

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

What would be simpler would be ending the use of leap seconds for a millennium or so.

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

#69

Post by Godel_unicode »

ChuckMcM wrote: post #56
EGreg wrote: post #51

Earlier quoted context omitted.

What if the stones move?

Guess we better use really large stones :-)

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

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

#70

Post by carbocation »

Godel_unicode wrote: post #69
ChuckMcM wrote: post #56

Earlier quoted context omitted.

Guess we better use really large stones :-)

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!)
Post reply on HN