Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should the leap second be eliminated?

bbc.co.uk

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Should the leap second be eliminated?

#11

Post by Splenivore »

gojomo wrote: post #6

I like the leap-hour once every 500 years or so idea. But I suspect in practice, it would never be actually assessed. When it comes due, everyone alive would be more accustomed to the 'hour off' times than the 500-years-ago time, so natural tendencies to eschew change in such matters would make following-through on the promised leap-hour unlikely.

We’re willing to shift our clocks by an hour twice a year to “save daylight,” whatever that means. Correcting for 500 years of clock drift is a far more tangible reason. It’s rather pessimistic to assume that the people of 500 years from now would be unwilling to implement this.

Re: Should the leap second be eliminated?

#12

Post by masklinn »

mseebach wrote: post #10
Gring wrote: post #8

Why don't we let GPS satellites and NTP broadcast both "regular time" and International Atomic Time (TAI), and let each user use the one that fits best? So: satellite navigation, financial services and flight control systems use TAI, everybody else uses regular time? To make the difference obvious and prevent misunderstandings, TAI could even have a different form, like a pure integer of "seconds after date X". So no…

I think you're on the right track, but I'd take it a step further: Whenever you're displaying what the time is to a human being, convert to UTC. In all other cases - especially storage and transmission etc. - use TAI. We have very rich libraries for dealing with time in software, so it's not like it would be a huge drag. There are still some unaddressed edge cases, of course. Say there's a leap second on 1 July. Now…

> We have very rich libraries for dealing with time in software

99.9% of which suck goats though.

And then, there's the problem of correctly syncing time display with internal representation: let's say the library stores time as a monotonically increasing number (which it should, ideally, that's the first failure of many libraries). This monotonically increasing number is then mapped onto "human" dates and times via more or less complex schemes.

The problem is that those mapping change over time, for instance the leap second is provided with 6 months of advance, DST/GST changes may be provided with far less (to say nothing of timezone changes). So those time libraries need to be updated all the bloody time or to have a mechanism through which they download mapping updates.

> conversely and perhaps more dangerous, should "14:00 30 June" + 24 hours come out as 13:59:59 or 14:00:00?

Well this is a human time mapping, in human time mappings the leap second is part of one of those 24h, so it'd be 14:00:00 (same as adding "1 day" or "1440 minutes"), whereas adding 86400 seconds would yield 13:59:59.

The internal storage should not have a concept of hours (or minutes, or even maybe seconds), it would have its "time unit" and then contextual mappings from the time unit to "human units" through calendars and calendar operations.

Re: Should the leap second be eliminated?

#13

Post by qntm »

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

Re: Should the leap second be eliminated?

#14

Post by rnadna »

There is no way to know whether a leap second will be used in the future, beyond the half-year "notice period". This can make it tricky to plan for synchronized events past the notice period. The solution, of course, is to use non-leaped time for such planning. As several have pointed out, libraries handle both times. As someone who needs to deal with both types in data processing, I can report that it's definitely not a big deal.

Re: Should the leap second be eliminated?

#15

Post by qntm »

Gring wrote: post #8

Why don't we let GPS satellites and NTP broadcast both "regular time" and International Atomic Time (TAI), and let each user use the one that fits best? So: satellite navigation, financial services and flight control systems use TAI, everybody else uses regular time? To make the difference obvious and prevent misunderstandings, TAI could even have a different form, like a pure integer of "seconds after date X". So no…

It seems[1] that GPS at least already broadcasts "GPS time", which is fixed at TAI plus 19 seconds, and hence doesn't include leap seconds.

[1] http://en.wikipedia.org/wiki/Global_Positioning_System#Timek...

Re: Should the leap second be eliminated?

#16

Post by extension »

Splenivore wrote: post #11
gojomo wrote: post #6

I like the leap-hour once every 500 years or so idea. But I suspect in practice, it would never be actually assessed. When it comes due, everyone alive would be more accustomed to the 'hour off' times than the 500-years-ago time, so natural tendencies to eschew change in such matters would make following-through on the promised leap-hour unlikely.

We’re willing to shift our clocks by an hour twice a year to “save daylight,” whatever that means. Correcting for 500 years of clock drift is a far more tangible reason. It’s rather pessimistic to assume that the people of 500 years from now would be unwilling to implement this.

Correcting for clock drift is not tangible in a practical sense though. We (allegedly) have good reasons for changing our schedule twice a year. Changing it because that's how people lived 500 years ago is not any kind of reason, and I think our ancestors will just laugh at the idea when it comes time for the leap hour.

So if these leap seconds are causing problems, I don't see any reason to keep them. By the time the consequences of getting rid of them are noticeable, they will no longer be negative consequences.

Re: Should the leap second be eliminated?

#17

Post by mseebach »

masklinn wrote: post #12
mseebach wrote: post #10

Earlier quoted context omitted.

I think you're on the right track, but I'd take it a step further: Whenever you're displaying what the time is to a human being, convert to UTC. In all other cases - especially storage and transmission etc. - use TAI. We have very rich libraries for dealing with time in software, so it's not like it would be a huge drag. There are still some unaddressed edge cases, of course. Say there's a leap second on 1 July. Now…

> We have very rich libraries for dealing with time in software 99.9% of which suck goats though. And then, there's the problem of correctly syncing time display with internal representation: let's say the library stores time as a monotonically increasing number (which it should, ideally, that's the first failure of many libraries). This monotonically increasing number is then mapped onto "human" dates and times via…

> 99.9% of which suck goats though.

The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on that (haven't used it though).

> And then, there's the problem of correctly syncing time display with internal representation [..] leap second is provided with 6 months of advance, DST/GST changes may be provided with far less (to say nothing of timezone changes).

Since the time zone issue is the larger one anyway, this provides a solid (copyright trolling aside) framework for distributing this information: a database distributed and maintained as part of the OS.

> Well this is a human time mapping [..] contextual mappings

I agree, but it's the context that's hard. You need some way for your abstraction to capture the fact that a "minute" can sometime consist of 61 seconds. Consider an application that monitors the number of foos per minute where the developer perfectly reasonable uses the "minute" abstraction. This might then exhibit faulty behaviour when there's a leap second inserted - suddenly there's 1/60th more foos reported in a minute.

Depending on the application, that might be statistically insignificant and can safely be ignored, or it might be a red flag that triggers someones pager to go off (or worse).

Re: Should the leap second be eliminated?

#18

Post by SquareWheel »

Splenivore wrote: post #11
gojomo wrote: post #6

I like the leap-hour once every 500 years or so idea. But I suspect in practice, it would never be actually assessed. When it comes due, everyone alive would be more accustomed to the 'hour off' times than the 500-years-ago time, so natural tendencies to eschew change in such matters would make following-through on the promised leap-hour unlikely.

We’re willing to shift our clocks by an hour twice a year to “save daylight,” whatever that means. Correcting for 500 years of clock drift is a far more tangible reason. It’s rather pessimistic to assume that the people of 500 years from now would be unwilling to implement this.

I think the counter-argument is the United State's resistance to metric, despite the obvious superiority to the system.

Re: Should the leap second be eliminated?

#20

Post by masklinn »

mseebach wrote: post #17
masklinn wrote: post #12

Earlier quoted context omitted.

> We have very rich libraries for dealing with time in software 99.9% of which suck goats though. And then, there's the problem of correctly syncing time display with internal representation: let's say the library stores time as a monotonically increasing number (which it should, ideally, that's the first failure of many libraries). This monotonically increasing number is then mapped onto "human" dates and times via…

> 99.9% of which suck goats though. The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on that (haven't used it though). > And then, there's the problem of correctly syncing time display with internal representation [..] leap second is provided with 6 months of advance, DST/GST changes may be provided with far less (to say nothing of timezone changes)…

> The past decade has seen immense improvements, though. JodaTime is pretty neat and JSR-310 seems to be an improvement on that (haven't used it though).

Joda is pretty much the 0.1% in question. On its own.

> I agree, but it's the context that's hard. You need some way for your abstraction to capture the fact that a "minute" can sometime consist of 61 seconds.

Absolutely.

> Consider an application that monitors the number of foos per minute where the developer perfectly reasonable uses the "minute" abstraction. This might then exhibit faulty behaviour when there's a leap second inserted - suddenly there's 1/60th more foos reported in a minute.

Ideally, this application should monitor the number of foos per [[time unit]], and only convert from [[time unit]] to minutes when it displays information.

Of course you'd still have contextual issues:

> Depending on the application, that might be statistically insignificant and can safely be ignored, or it might be a red flag that triggers someones pager to go off (or worse).

Yeah. Unless those triggers use the rate per [[time unit]] instead of using the rate per "human" unit (would blow up on summer time end as well, as it "replays" a full human hour)

Post reply on HN