3 ms·

This article doesn't give clear enough reasons for abolishing leap seconds. One passage says: > But those seeking to abolish the leap second say these one-seco

by qntm 15y ago

This article doesn't give clear enough reasons for abolishing leap seconds. One passage says: > But those seeking to abolish the leap second say these one-second jumps are becoming increasingly problematic for navigation and telecommunication systems that require a continuous time reference. These include satellite navigation, financial services, the internet, flight control and power systems, among others. But elsewhere, > Ron Beard, chairman of the ITU's working party on the leap second, said: "This is not a technical issue, it is more a diplomatic one."

drostie 15y ago
Well, let me phrase it a little more analytically, then. The biggest reason to switch UTC to atomic time is hacker-cultural. Basically, many countries have said, in law, "we use UTC." This causes most specifications -- in particular NTP, Javascript, and POSIX timestamps -- to also say "we use UTC -- but we ignore leap seconds." Unfortunately, these specifications are thereby rendered useless and incompatible in a bunch of different ways. NTP servers, we'd like, should just broadcast atomic time, TAI. Similarly, Javascript's Date.getTime() should give TAI, and POSIX should give TAI. But TAI isn't what countries have legally specified -- UTC (and in some cases GMT) is what countries have legally specified. Governments use UTC because we like the idea that the sun rises at around 6 AM. (Or, on my base-10 clock, at around 0 ki.) But that's when the sun rises -- that's a question of setting a time zone! So the best way to include leap seconds for now is via time zone information: allow the time zones to drift with leap seconds. Time zones are already pretty crazy and hard-to-anticipate and may change by a much larger offset at even shorter notice (e.g. "This summer, we are not observing Daylight Savings time"). If you can't anticipate upcoming political "leap-hours", your software already can't handle the less-political question of "when is the next leap-second?" During my free time I've been playing with designing a base-10 clock. (Obligatory plug: http://drostie.org/time/ http://drostie.org/time/ .) So I've been thinking about this topic off-and-on for a couple years now. During that time I guess I've convinced myself that the right way to handle this is to define a named time zone which implements leap seconds -- this requires derivative time zones. So for example, my clock above automatically assigns to New York the base-10 time zone of "+300". With named time zones, it could shift to leap seconds by passing a law saying "the base-10 time zone in our jurisdiction is instead leap+300." Or perhaps the US as a whole would design their own time zone to standardize a base-10 daylight savings time, and call it "us" and then New York might be in the time zone "us+300". The goal is to really make specifications designers think, "oh, leap seconds are a cosmetic choice, I'd better just use the base-10 'rational timestamp' format rather than rolling my own implementation of POSIX timestamps." Right now they think "oh GMT is old and UTC is new and everyone knows what UTC is so we don't have to worry about it, right?" -- and they don't get it right. So is this a technical issue or a diplomatic one? Well, it's technical because it affects technical specifications, but it's nontechnical because there is no good technical argument for using UTC versus TAI -- that's a time zone question, a political or diplomatic question about when you want the Sun to rise. The only technical situation that I know of is the claim that some old telescopes might be using time to find stars -- and might misalign if the time comes unsynchronized from Earth's rotation. I don't consider this a serious technical difficulty, because those telescopes are manned by hackers smart enough to get a feed of Terrestrial Time and pipe it into whatever clock input was receiving UTC. "Hey look, it uses this NTP server, let's just redirect that DNS query to a smallish Linux box which serves TT over NTP." I think we're smart enough to ignore this technical case.

by qntm 15y ago

drostie 15y ago

Well, let me phrase it a little more analytically, then. The biggest reason to switch UTC to atomic time is hacker-cultural. Basically, many countries have said, in law, "we use UTC." This causes most specifications -- in particular NTP, Javascript, and POSIX timestamps -- to also say "we use UTC -- but we ignore leap seconds." Unfortunately, these specifications are thereby rendered useless and incompatible in a bunch of different ways. NTP servers, we'd like, should just broadcast atomic time, TAI. Similarly, Javascript's Date.getTime() should give TAI, and POSIX should give TAI. But TAI isn't what countries have legally specified -- UTC (and in some cases GMT) is what countries have legally specified. Governments use UTC because we like the idea that the sun rises at around 6 AM. (Or, on my base-10 clock, at around 0 ki.) But that's when the sun rises -- that's a question of setting a time zone! So the best way to include leap seconds for now is via time zone information: allow the time zones to drift with leap seconds. Time zones are already pretty crazy and hard-to-anticipate and may change by a much larger offset at even shorter notice (e.g. "This summer, we are not observing Daylight Savings time"). If you can't anticipate upcoming political "leap-hours", your software already can't handle the less-political question of "when is the next leap-second?" During my free time I've been playing with designing a base-10 clock. (Obligatory plug: http://drostie.org/time/ http://drostie.org/time/ .) So I've been thinking about this topic off-and-on for a couple years now. During that time I guess I've convinced myself that the right way to handle this is to define a named time zone which implements leap seconds -- this requires derivative time zones. So for example, my clock above automatically assigns to New York the base-10 time zone of "+300". With named time zones, it could shift to leap seconds by passing a law saying "the base-10 time zone in our jurisdiction is instead leap+300." Or perhaps the US as a whole would design their own time zone to standardize a base-10 daylight savings time, and call it "us" and then New York might be in the time zone "us+300". The goal is to really make specifications designers think, "oh, leap seconds are a cosmetic choice, I'd better just use the base-10 'rational timestamp' format rather than rolling my own implementation of POSIX timestamps." Right now they think "oh GMT is old and UTC is new and everyone knows what UTC is so we don't have to worry about it, right?" -- and they don't get it right. So is this a technical issue or a diplomatic one? Well, it's technical because it affects technical specifications, but it's nontechnical because there is no good technical argument for using UTC versus TAI -- that's a time zone question, a political or diplomatic question about when you want the Sun to rise. The only technical situation that I know of is the claim that some old telescopes might be using time to find stars -- and might misalign if the time comes unsynchronized from Earth's rotation. I don't consider this a serious technical difficulty, because those telescopes are manned by hackers smart enough to get a feed of Terrestrial Time and pipe it into whatever clock input was receiving UTC. "Hey look, it uses this NTP server, let's just redirect that DNS query to a smallish Linux box which serves TT over NTP." I think we're smart enough to ignore this technical case.