Next Chapter In the Leap Second Story 68
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 (Score:5, Informative)
Re:Double time (Score:5, Funny)
I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.
Re: (Score:2)
I'm going to try this in Kerbal Space Program. If it works, I'll let NASA know.
Re: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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 (Score:5, Informative)
There's good coverage here.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Huh?
Re: (Score:3)
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: (Score:3)
"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: (Score:1)
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: (Score:1)
Re: (Score:3)
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.
'taint no such thing. There's UTC, an
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 (Score:4, Interesting)
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: (Score:2)
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: (Score:2)
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: (Score:1)
"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 (Score:3)
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: (Score:2)
Re: (Score:2)
Re: (Score:1)
For leap seconds I just let NNTP correct it, so it has never been an issue in the first place.
Re:adjustment (Score:5, Funny)
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: (Score:2)
I just wait for the flamers to disappear up their own assholes :-)
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
All the more reason not to throw in another hour to adjust by (or ignore) somewhere.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
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.