Was glad things have improved since 4 years ago!
https://blog.fastmail.com/2012/07/03/a-story-of-leaping-seco...
This time I didn't get paged for anything on leap second day :)
Some DNS lookups causing 5xx errors due to leap second bug
91–100 of 135 posts
Re: Some DNS lookups causing 5xx errors due to leap second bug
#92Earlier quoted context omitted.
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…
"00:00:00 on January 1, 2020" UTC is a rather useless timestamp for most practical purposes, unless you live close to th zero meridian. In most places you want to talk about 00:00:00 on January 1, 2020 localtime, which depends on what timezone you are in, and of course the daylight savings rules. Both can change. In some countries, daylight seems to be even more random than leap seconds.
In my opinion, the real problem is that TAI is not an option in most current systems. There is no way to get the time in TAI, no way to convert between TAI and UTC etc.
So even in applications where it makes sense to use TAI (think logging and billing) we don't do that because the necessary infrastructure is not available.
I think it is time that the technical community gets together can make TAI a first class citizen.
TAI doesn't help with timestamps in the future, but usually those applications don't need second level granularity anyhow. The applications that break during a leap second are the ones that need to track the current time or passage of time with sub-second accuracy. And those can be served perfectly with TAI.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#93Earlier 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
That's really odd. You can't even make a working progress display without that.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#94Once 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?!
This isn't exactly HN style, but here ya go...
https://s-media-cache-ak0.pinimg.com/originals/f3/f7/7e/f3f7...
Re: Some DNS lookups causing 5xx errors due to leap second bug
#95Earlier 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…
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, 2016: that would have been scheduled for 06:00 UTC. When Egypt cancelled daylight savings with three days notice, that record should then have been 07:00 UTC.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#96Earlier 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…
That one is called ephemeris time (ET). Astronomical applications require the information of the current difference UT-ET.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#97Earlier 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.
You should store that similar to this:
begin = (today, 12:00) (eg. 2017-01-01T12:00:00)
repeat = RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
Re: Some DNS lookups causing 5xx errors due to leap second bug
#98Earlier 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…
Another neat example in the "UTC ain't always the right thing to do" category.
Re: Some DNS lookups causing 5xx errors due to leap second bug
#99Funny that they wrote about it in 2014 https://blog.cloudflare.com/its-go-time-on-linux/
Re: Some DNS lookups causing 5xx errors due to leap second bug
#100Half the people posting here need to read https://qntm.org/calendar