Next Chapter In the Leap Second Story

at10u8 writes "The ITU-R and BIPM are holding a joint workshop on the Future of the International Time Scale. This is the next of many steps toward the possibility that radio broadcasts of time signals might abandon leap seconds. All of the presentations are online and the press release for the workshop indicates there will be video interviews afterwards."

articles by the workshop participants

[at10u8]

The ITU has also put up an issue of ITU News with in depth articles [itu.int].

Re:Double time

[presidenteloco]

I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.

Re:

[bondsbw]

I'm going to try this in Kerbal Space Program. If it works, I'll let NASA know.

Re:

[FatdogHaiku]

I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.

But the bad news is we all have to get out and push!
Personally I think if they legalize weed no one would worry about a second here or there...

Re:

[rvw]

I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.

With GTA V out, we just have to get everyone to drive eastward.

Re:Double time

[aardvarkjoe]

So... err... how will it go now? Instead of posting a 60th second they will make the 59th second twice as long, and have everyone think their clocks are fast, accept that out of sync clocks are a fact of life, and just synchronize?

They'll simply stop trying to correct UTC to match the rotation angle of the earth. "Correcting" UTC that way is mostly helpful to astronomers, and for everyone else has no benefit and some significant drawbacks.

Re:Double time

[msauve]

Civil time has always been based on the sun. For anyone who doesn't like dealing with leap seconds, there are well established alternate timescales available which don't use them, such as GPS and TAI. There is no good reason to eliminate leap seconds from UTC, which was very specifically developed to closely track the earth's rotation, like its other UTx siblings [wikipedia.org]. The people who want to eliminate leap seconds from UTC are the ones who chose their timescale poorly, and now want those who use it properly to suffer for their mistakes.

There's good coverage here.

Re:

[msauve]

missing link [ucolick.org]

Re:

[Greyfox]

Except no one seems to know the difference, and it's literally impossible to know an accurate time in a system involving more than one component. Accidentally make the adjustment twice and you're in as bad shape as if you hadn't made it in the first place. I E-mailed a developer about a piece of a spec that didn't specify and asked him if the time was GMT or UTC. His response was "What's the difference?" Not something you want to here from someone who maintains astronomical software. Other parts of the spec

Re:

[Greyfox]

POSIX specifies leap seconds aren't included. POSIX also states that times are UTC. But it SPECIFICALLY says that leap seconds are not included. It doesn't say UT1. It says UTC, no leap seconds. And that's why man with one watch doesn't know what time it is.

Linux mostly follows POSIX but has the ability to include leap seconds if you want them. IIRC, NTP includes leap seconds (Which occasionally breaks both NTP and various OS kernels.)

Re:

[Forever Wondering]

Perhaps it's time to go the other way and use GPS/TAI for computer clocks instead of UTC. In other words, perhaps civil time should be changed. Just because it used to be based on something doesn't mean it needs to be in the future.

Leap second adjustments at the time that they occur are problematic for OS scheduling during that period. Also, you have to maintain a table of whether the twice a year leap second has been applied [and in which direction]. The table must be updated every six months because a

Re:

[rk]

Because the leap year doesn't have anything to do with time of day, but the position of the earth regarding its axial tilt in its orbit. If we quit using leap year days, noon would still be more or less noon every day but the seasons would start marching forward in the calendar and spring would start in April, then May...

Re:

[msauve]

It's perfectly reasonable to ask that legal systems change to something other than UTC, if avoiding leap seconds in civil time is beneficial.

Leap seconds can occur in any month, there's simply a preference that they occur the end of June or December. But, worldwide, there are more significant adjustments to be made, on a more random basis, due to meddling with time zone offsets and summertime dates.

Leap second adjustments at the time that they occur are problematic for OS scheduling during that period.

Huh?

Re:

[Forever Wondering]

Leap seconds are problematic not because of sloppy coding but because they are a messy problem.

During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified? If you're compiling, an object file may be updated or not. Or, with rsync, a file may be transferred or not. Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?

Also, applic

Re:

[Pinky's Brain]

"During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified? If you're compiling, an object file may be updated or not. Or, with rsync, a file may be transferred or not."

Only with negative leapseconds, which have never been used ... as long as the timebase is monotonic these shouldn't fuck up. As for POSIX using a timebase which might not be always monotonic for file timestamps ... well that is sloppy coding. The sloppy coding being part of POSIX is no

Re:

[Megane]

Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?

You know a radialogist who works at 2AM on Sunday?

Re:

[Megane]

Grrr... I realized as I clicked the button that leap seconds happen at midnight. But still, you know a radiologist who works at midnight? People aren't just left sleeping in that kind of medical equipment with no operator. Also, if someone is basing elapsed time (of less than an hour or so) by subtracting two time readings (rather than using a millisecond uptime timer from the OS), they're an idiot.

Re:

[msauve]

During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified?

Whoosh.

You're not describing a problem, you are the problem. If an event occurs during a leap second, you simply timestamp the time, 23:59:60.x. What you describe simply demonstrates the problem with incorrect assumptions and sloppy coding: that a minute can't have more than 60 seconds. That hasn't been the case for over 40 years.

based on POSIX-compliant UTC

'taint no such thing. There's UTC, an

Re:

[Forever Wondering]

During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified?

Whoosh.

Whoosh yourself ...

You're not describing a problem, you are the problem. If an event occurs during a leap second, you simply timestamp the time, 23:59:60.x.

Yes, that's what the spec talks about. But, it isn't how times are represented internally in systems. They use binary [64 bit] numbers that are [usually] offsets from Jan 1, 1970 [the Unix epoch]--except for MS, of course.

It's what happens to a [normally] monotonic sequence: n,n+1,n+2 when you present n,n,n+1 or n,n+2,n+3 instead at the binary level and how you handle the discontinuities [if you're even in a position to know the discontinuity has occurred]. Most software just sees any

Re:

[msauve]

Just. Wow. You don't know what "monotonic" means. You don't know what a discontinuity is. You don't know how to do subtraction. You obviously suck at programming. You don't know the difference between a normative standard and an informative statement. No wonder you have problems dealing with relatively simple matters like leap seconds.

Re:

[at10u8]

Look deeper at one of the underlying problems in this issue -- see blockquote in the "UTC in 1982" entry here [ucolick.org]. That paragraph was written by one of the folks who actually worked in the field of timekeeping, and those are the folks who produced the documents that get approved by the votes. (All the votes by those agencies that make the official documents are done by delegates who know next to nothing about the subject matter.) See how that 1982 paragraph crows about the way that UTC with leap seconds has

Re:

[Forever Wondering]

Yes. From the blockquote: "constitute a powerful endorsement of the carful work". Guess somebody wasn't carful "E"-nough :-)

The self congratulation aside, they had different goals at that time. They were looking for a unified/legal definition of time that could be universal.

I don't think even many programmers realized the implications at the time either. I mean, Intel was rolling out 5Mhz chips then. The focus was rolling out PC's as a credible alternative to the mainframe world. As the CPU's sped up

Re:Double time

[rk]

This. If you don't want leap seconds and don't care if you're synchronized to the sun, you already have two timebases to choose from. Do this and you take away a use case from others, and then have THREE to choose from.

Re:

[AmiMoJo]

Most people don't have a choice, they have to work with some protocol that chose UTC without really understanding the issues many years ago.

Re:

[cjameshuff]

It's not even helpful to astronomers. Your telescope's direction will jump by 15 arcseconds for every leap second applied. If you want precise pointing, you'll use a rotation model based on more detailed data on Earth's rotation with a timebase that's actually real time, not some mostly-increasing number with arbitrary jumps forward and back.

Re:

[evanh]

"Everyone else" doesn't much care either way. I think you'll find it's just as few people that think it shouldn't be a moving target.

I don't see why leap seconds has ever been an issue. Date-stamping has always been a fickle mechanism that always shifts around according to whatever governments decide.

Metronomic sampling on the other hand doesn't give a shit about the calender and only cares about regular timing.

The two systems, sampling and date-stamping, should not be confused and the one should not dict

adjustment

[rossdee]

cant they just do these adjustments when we are scheduled to do the switch to or from daylight saving time since you have to fiddle with the clock anyway

Re:

[complete loony]

They should just stick to one standard frame of reference, similar to GPS time. The translation to local timezones could include leap seconds if you want it to. Conversions to local timezones already has some ambiguity as you mentioned due to daylight saving time. Software developers need to abandon the idea that datetime values in your local timezone can be stored, compared and used in calculations as only a single number.

Re:

[complete loony]

Exactly, which would force you to store every datetime with the relevant timezone instead of assuming all of your datetime values are in the same zone. Which is essentially what I implied.

Re:

[sjames]

For leap seconds I just let NNTP correct it, so it has never been an issue in the first place.

Re:adjustment

[the_other_chewey]

For leap seconds I just let NNTP correct it, so it has never been an issue in the first place.

Impressive. How did you solve the problem of time dilation due to flame wars?

Re:

[sjames]

I just wait for the flamers to disappear up their own assholes :-)

Re:

[thegarbz]

Which daylight savings? In what territory of what timezone? When you switch your clocks is not the same when I switch my clocks (hint: never). Not to mention that some clocks change at a different month than others.

So far we need to keep track of timezones and daylight saving time, and even massive companies fail to be able to do this correctly without issue (Apple isn't the only one). Do you now propose we keep track of which subsections of which timezone are a second ahead or behind given the arbitrary ap

Re:

[jon3k]

God no, don't tie something practical like leap seconds to an arbitrary daylight savings scheme. Just abolish daylight savings.

Re:

[lgw]

The proposal seems to be a bit of a legal hack. You could switch to TAI for civil purposes, but then many countries would need to amend many laws to say "TAI" where they now say "UTC", and all those legal changes should happen together for sanity, which is a bit impractical. Or, you could just change the definition of "UTC" and then all those countries laws change seamlessly together.

Re:

[sjames]

I suspect iot's more like the law says whatever it does and it's worked well enough so far. The last thing they need is for UTC to be randomly redefined out from under them. I propose we define UTC to be TAI + a randomly selected value between 0 and 3600 (known hereafter as WWTW aka wibbly wobbly timey wimey) just to screw with them.

Re:

[lgw]

Everyone on both sides of the political debate seem to agree that leap seconds are just an annoyance, the division seems to be between "let's do this trick" and "it's not annoying enough to change anything, just leave it be".

I never really understood the motivation for leap seconds myself - it's not all that helpful for pointing a telescope, and for all non-astronomers it's just annoying. Far better to adjust by an hour at one far future point when GMT is "off" by a full hour than to constantly tinker with

Re:

[sjames]

An adjustment of an hour can be a real annoyance, adjusting by a second is lost in the noise. There are much larger consequences if a closk is off by an hour, practically none if it is off by a second. People who grew up before clocks synchronized by radio or the cell network even expect clocks to be off by more than a second but off by an hour is noteworthy..

Re:

[xenobyte]

An adjustment of an hour can be a real annoyance, adjusting by a second is lost in the noise.

That's why good sysadmins run their systems on UTC, only converting to local time for display purposes. Daylight Savings Time (or summer Time) and its one hour jumps is a huge pain in the butt and people running cron according to local time have to handle jobs being skipped or jobs being run twice. Sure, using UTC the jobs are off by an hour during the summer but that really shouldn't be that much of a problem. Making sure they run and run only once is more important.

Alternatively - useful if you have jobs

Re:

[AmiMoJo]

A lot of industrial devices ignore DST. It's just too much hassle to implement and can break things like schedules. You don't want any unpredictable behaviour in an industrial process or sensor network.

Re:

[sjames]

All the more reason not to throw in another hour to adjust by (or ignore) somewhere.

Re:

[lgw]

Clocks aren't "off" unless they disagree with whatever standard time is. If we remove leap seconds from UTC, then all clocks that don't have leap seconds (you know, like most actual clocks that exist in the world) will keep correct time.

Adjusting by an hour 300 years from now is a small cost.

Re:

[sjames]

Most clocks now DO have a loose tracking of leap seconds. They are either adjusted by NTP silently, are slaved to a clock adjusted by NTP or that is otherwise adjusted, or they are free running but occasionally corrected to match such a clock.

It works so well as it is that many people don't even know leap seconds are a thing but their clocks are right.

Re:

[lgw]

Most clocks still hang on the wall, or sit on an end table, or are worn on the wrist. Though perhaps we'll cross over some time this century to where there are more cell phones than discrete clocks, I guess. Hell, I have 2 clocks in my car, and only one is synced to an external source, which is quite odd twice a year.

It occurs to me that the best time to make the odd adjustment would be years evenly divisible by 400 - instead of a leap day, we'd have a leap hour-or-so. That's the point at which the "adju

Re:

[sjames]

And all of those wall clocks, wrist watches, etc are periodically synced up with cellphone, computer (set by NTP), whatever the TV station says (set by time standard), etc. They are the third type I mentioned. Since they are not expected to be accurate to the second, the periodic adjustment will track close enough over the years. Why make them all suddenly wrong beyond the expected minute or two one fine day in the future?

And yes, WRONG as in clock at home (missed the update) disagrees by an hour with clock

Re:

[lgw]

The Sun only needs to loosely correlate. If UTC was changed to be 24*3600 seconds per day, period, that would be close enough for decades, even centuries at a time (and if it drifts slow enough, whatever it is it whatever it's been you're whole life).

It's just far simpler to have a system of time that could be kept mechanically, with a "solar correction" every 100 years (which we already do! we skip leap days) . And, really, if we had any kind of vision as a species, why would we care about where the Sun i

Re:

[sjames]

Really, how practical. We do not today, nor are we likely within our lifetimes to have a significant number (if any) of humans on any other planet. We do have a significant number of activities that either depend on the sun or work better when scheduled with the sun. Why shouldn't our time track it at least until we actually do have a significant population elsewhere (even then I suspect we'll mostly stick to local time and only use the more universal time when interacting with those other people).

And those

Re:

[at10u8]

Yes "right" is "agree with everyone else", but in the existing documents by which various international agencies approved the use of UTC all of them did so along with an assertion that everyone was agreeing with "mean solar time"; i.e., that days are counted by measuring the rotation of the earth. Those engineers who are free to ignore regulations and statutes can choose to use something like GPS time, but many projects and systems are constrained to conform to existing regulations and do not have that lib

Re:

[lgw]

But this is a debate about what those very statutes should be, not about what some geeks will do. Seriously, who cares about POSIX? The general consensus seems to be "leap seconds are bad", because agreeing with solar time only loosely matters in the first place, and simpler is always better. The argument is over whether it matters enough to change anything.