But… but… That would mean that at the end of my life, UTC time will be a whole minute out of sync with the rotation of the earth!?
Boffins debate killing leap seconds to help sysadmins
Boffins from the International Telecommunications Union (ITU) and the International Bureau of Weights and Measures ( known as the BIPM for its French name: Bureau International des Poids et Mesures) have met to discuss redefining time. Specifically, they're keen to redefine Coordinated Universal Time (UTC), the international …
-
-
Monday 23rd September 2013 08:32 GMT Anonymous Coward
Terrible I say...
What I find funny though is why do we need leap seconds? doesn't that mean when the second was defined they made a mistake and the second is a TEENY bit too slow?
Surely we can easily predict when we need leap seconds, couldn't a non-connected machine be programmed to insert them at the right time?
I'm sure all the 'cloudy' guys will be having chest pains at the idea of something not being connected up!
-
Monday 23rd September 2013 09:23 GMT Owain 1
Make them predictable
I agree with this thinking. I.e. instead of them deciding each time they need one, if they simply agreed that they would add some at predefined times. (Say 30th June in 2013, 2018, 2025, 2029 etc) to keep time with the predetermined slow down of the earths rotation, then we'd just have a fixed list that lasted 50 years or so. Then we'd all be dead and the children can think about how/ when to add more to that list.
Easy to implement (simply publish them, and then stick to them). Easy to embed in closed systems (just used published seconds - no system is likely to last more than 50 years with no maintenance).
And they could simply decide not to add any more leap seconds at all. That way there is no need to change existing systems (they just read the existing leap seconds from the existing list) and you don't need to change any embedded systems either. The GPS and 'updated' clocks are simply defined as being 18 seconds apart from each other from now on.
Everybody is happy.
-
Monday 23rd September 2013 09:48 GMT Destroy All Monsters
> Surely we can easily predict when we need leap seconds, couldn't a non-connected machine be programmed to insert them at the right time?
You wish!
Slowdown however depends on many random effects - tides, air pressure, random displacements of masses within the earth's interior, continental drift etc. So it's not particularly deterministic.
-
Monday 23rd September 2013 18:34 GMT tom dial
I seem to recall that the rotation of the Earth is not quite uniform, perhaps due to sloshing of oceans and the Moon's orbit not being quite a perfect circle. If so, and if that is not fully predictable, it would seem the uniform clock also might need occasional resetting. I'm OK with NTP and a leap second now and then, along with occasional resetting of my pendulum clocks.
-
-
-
Monday 23rd September 2013 12:01 GMT JLH
Re: What a truly advanced civilization would do
"Of course, the proper fix would be to adjust the rotation of the Earth to stay in sync with the atomic clocks!"
Easy-peasy. Take some of those surplus Russian atomic bombs the equator, up a high mountain. Maybe Mount Kilimanjaro? Set them off.
Job's a good 'un.
See Project Orion for references.
-
Monday 23rd September 2013 12:46 GMT Armando 123
Re: What a truly advanced civilization would do
"Of course, the proper fix would be to adjust the rotation of the Earth to stay in sync with the atomic clocks!"
Mmmmyessssss .... Going to be a bit difficult getting the moon to agree to that, isn't it? That sort of energy would require burning everything from fossil fuels to orphans.
-
Tuesday 24th September 2013 04:42 GMT MacroRodent
Re: What a truly advanced civilization would do
That sort of energy would require burning everything from fossil fuels to orphans.
Yes, currently, but I was talking about a advanced civilization. We are not yet even at level I on the Kardashev scale.
-
-
-
-
Monday 23rd September 2013 07:24 GMT Kevin McMurtrie
It isn't
GPS time and other atomic clock systems (TAI) are continuous but Unix time isn't. To convert from an atomic clock to Unix UTC, you must shift the epoch and run through the leap second list.
The difference between UTC and Unix time is that UTC will add leap seconds by ending a day at after 23:59:60 than after the usual 23:59:59, thereby maintaining perfectly unique timestamps. Unix time can't do that so it repeats a second.
-
Monday 23rd September 2013 08:29 GMT Anonymous Coward
Unix time
@ A Non e-mouse: Unix time is the count of non-leap seconds since 1st Jan 1970. That is to say, it is not continuous. Strictly speaking it pauses for the duration of a leap second, practically of course on almost all systems it ploughs on regardless and gets corrected afterwards by NTP.
That said, we do have a continuous time parameter in common use in consumer devices. GPS time is the count of seconds since 6th January 1980.
The "big" difference that this change would make is that devices with GPS but no internet will be able to use GPS time to compute the "user friendly" time. They can't do that at the moment because leap seconds aren't predictable, so without an internet connection (or some other means of update) you can't tell how many have happened since 1980 (currently 16).
I don't own any clocks more accurate than 1 second in 2 years, and I think for the average person GPS is their best chance of having one. That said, IMO 2013 is a bit of a weird year to start worrying about non-connected devices. In terms of capability this measure seems to cover the very narrow gap that starts when GPS becomes easy, and ends when connecting to the internet becomes easy. In terms of cost, I don't know how much leap seconds do cost, but for most uses their effect is negligible compared with the inaccuracy of your on-board time-keeping device. Removing them from the equation doesn't really help because you still need *some* external source of accurate time.
-
-
-
-
Monday 23rd September 2013 08:14 GMT Nextweek
Re: If only there was a way for computers to send data to each other...
I think you should go look up GPS clock PCI cards. You'd only need one on a closed network to keep everybody on that network in sync. More if you want security.
For the cost of a £200 PCI card its not worth the risk of changing how we currently work with clocks. We'll have 50 years of legacy data with leap seconds, which some future programmer will forget to cater for.
The risks of the system are being catered for, no need to rock the boat.
-
Monday 23rd September 2013 08:37 GMT dkjd
Re: If only there was a way for computers to send data to each other...
The main problem is that GPS satellites don't do leap seconds, so GPS time is already 16 seconds out from UTC. Also you cannot predict when you will need leap seconds as it depends upon the weather on top of the mountains, which affects the amount of ice that accumulates in winter which affects how fast the earth rotates.
-
-
Monday 23rd September 2013 10:51 GMT Paul Crawford
Re: @John G Imrie
Closed network on a power station? Then buy at least two GPS and LW equipped time servers for redundancy.
For example:
http://www.galsys.co.uk/ntp-servers/nts-6001-dual-ntp-server.html
http://www.timetools.co.uk/ppc/ntp-time-server.htm
http://www.meinbergglobal.com/english/products/rail-mount-ntp-server.htm
http://www.spectratime.com/products/ireference/
Simplez!
-
-
-
Monday 23rd September 2013 07:30 GMT Paul Crawford
Oh FFS!
So in order to deal with incompetent or poorly tested OS designs that don't actually bother to address the definition of time that has been around for several decades, they want to break compatibility with anything that actually uses that definition by assuming that Earth rotation is never more than +/-1 sec from UTC?
A triumph of the incompetent many :(
Why don't they just tell folk to fix their software, its not a new problem after all?
And for those devices that are not connected to "know" about leap seconds, how exactly would they be keeping accurate time in the first place, and even if they do, how would that matter if they don't interact with systems that are kept in sync?
-
-
Monday 23rd September 2013 09:27 GMT John H Woods
Re: surely?
justincormack: "My computer does not need to measure the rotation of the earth. It does however need to agree what the time is with other computers for security reasons. It might also have to tell humans to do stuff at particular times, but that need not be that precise."
I'm not sure whether you are agreeing with the previous poster or not. But the key point is "agreeing with other computers". This implies a shared authoritative source of time: if not from the internet, then from GPS, and if not from GPS then one of the computers' relatively inaccurate on-board clocks will have to be considered the authorative time on that isolated network.
-
-
-
Monday 23rd September 2013 07:35 GMT Anonymous Coward
Every system I saw without a time reference to update its clock...
... usually has no really any idea about what time is. There is not only NTP, there are radio and GPS receivers to update time when needed. System employing none of the available systems usually have clocks out of sync of several minutes - can't really see how leap seconds can be an issue for them.
If we are talking about systems who have a time reference but can't handle leap seconds properly it's another matter.
-
Monday 23rd September 2013 07:41 GMT Paul Crawford
Bollocks presentation
Have you read the linked slide show? Three obvious political-style lies are included:
Page 6 - "Leap seconds interrupt normal operation of timekeeping infrastructures and are costly in staff time to implement" - no, you use NTP and it just happens! Unless the system gets broken due to bad/untested software, you need no interaction whatsoever.
Page 6 - "On June 30, 2012, every clock in the world had to stop for one second" no the fscking did not "stop", they simply stepped one second when needed. If you rely on a basic time-stamp then you might get it repeated, etc, but if monotonic time actually matters deeply for program flow or synchronisation, you use one of the system supplied functions that gives you that. (e.g. clock_gettime() with the CLOCK_MONOTONIC flag) or you implement your code to cope in other ways.
Page 12 - "and significant cost reduction in their implementation" - no, you use a system-supplied library that handles time correctly and then only one competent programmer needs to do it, and everyone else "just works". Having monkey-grade programmers implementing basic time keeping over and over again, and getting it wrong (by not RTFM) is a sign of a far deeper problem in your organisation and choice of staff.
How to we get this joker to correct this and apologies?
-
Monday 23rd September 2013 08:05 GMT James Chaldecott
Re: Stopped clocks
Not only do the clocks not stop, but it's quite simple to make sure they don't repeat (or skip) seconds either. (As you say; thinking this through only needs doing once.)
Interestingly enough, the first I read about this was this post, which talks about how Windows deals with small adjustments coming through NTP (search for "System clock changes"):
http://blogs.msdn.com/b/rxteam/archive/2012/06/20/reactive-extensions-v2-0-release-candidate-available-now.aspx
I swear that it was only a couple of weeks later that there WAS a leap second introduced that caused a bunch of servers somewhere important to get their knickers in a twist, and Google announced that they had a patch in their version of Linux that made it do the same thing. I was surprised at the time that it didn't already.
Ah! Here it is:
http://www.theregister.co.uk/2012/07/02/leap_second_crashes_airlines/
http://googleblog.blogspot.co.uk/2011/09/time-technology-and-leaping-seconds.html
Looks like they adjusted their internal NTP servers. Interesting. That still doesn't describe how a standard linux system will deal with this then. I won't speculate, as I know next to nothing about these things, really.
-
Monday 23rd September 2013 08:25 GMT Paul Crawford
Re: Stopped clocks
AFIK the leap second problem that affected Linux last year was down to some timers getting dead-locked, and that was due to a kernel patch that broke the previously correct time-handling for leap seconds. And nobody realised or tested it until the live event:
http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html
A short check shows a RedHat article including a leap second simulator so you can test a system for its behaviour to debug this predictable event:
https://access.redhat.com/site/articles/199563
While a big event, it just shows the price you pay for not testing something for all expected conditions.
Google slew their machines over 1 day, so no step but also same long-term behaviour. Of course, during that day they are up to 1s out, but clearly that is no big deal for them.
-
Monday 23rd September 2013 08:29 GMT Anonymous Coward
Re: Stopped clocks
ntpd will make small adjustments by skewing the wall time clock and large adjustments by stepping it.
Following a leap second the system learns from NTP that its clock is suddenly a second fast, then gradually brings it back into synch with the external time. Instead of stopping for a second, or repeating a second, it will in effect stop/repeat a few milliseconds at a time for a while.
I suppose it's possible that this behaviour can be changed, and/or is different by default on some distros. Since I don't actually care I've never verified. I have much worse problems than leap seconds keeping accurate time on the linux boxes I manage, the principle one being VMs whose clock is tied to the host, and whose host clock is incorrect.
-
Monday 23rd September 2013 08:35 GMT Paul Crawford
Re: Stopped clocks
In the Linux case it knows (from NTP) that a step is pending, and it jumps accordingly. The ntpd slewing/stepping is for "normal" time errors.
How VMs handle this is another story. From our experience VM timekeeping is pants anyway, so this is just another minor issue. If an OS/application really needs good timekeeping for some task (e.g. audit of network delays for security such as MITM detection), it really has to run on a physical machine.
-
-
-
Monday 23rd September 2013 15:52 GMT Cynic_999
Re: Bollocks presentation
The main problem with leap seconds is that it becomes possible to have two computer events logged out of sequence. Computers are fast enough that many events can happen during one second - so consider the following:
23:59:59.75 = Event 1
00:00:00.00 = Event 2
00:00:00.25 = Event 3
00:00:00.50 = Event 4
00:00:00.75 = Event 5
00:00:01.00 = Event 6
Now imagine that there is a leap second - in that case the time stamp of event 6 will not be 00:00:01:00 but the leap second puts it back to 00:00:00.00 - which would log Event 6 as occurring before events 3,4 and 5
IOW if an event happens to be logged at 00:00:00.xxx on a leap second day, the software will not be able to determine whether that was the first 00:00:00.xxx or the second (leap) one.
As the article states, you need to represent the leap second with a unique time stamp such as 00:00:60.xxx, which would require a heck of a lot of software to be updated to handle such a time.
-
-
Monday 23rd September 2013 07:54 GMT Paul Crawford
The UK's position
Thankfully, it seems the UK's position is sensible, as covered here:
http://www.itu.int/dms_pub/itu-r/oth/0a/0e/R0A0E0000960014PDFE.pdf
Basically they point out that not only would it mean that "1 day" in no longer synchronised to the Earth's rotation as common sense expects, but that you either end up with a long term problem of sun rise/set getting seriously out of sync with our working hours, or you have bigger but less frequent steps which are worse then a 1-2 year leap second in terms of impacting badly designed systems.
Really, why don't they just make proper time-keeping a mandatory requirement for software systems and force vendors to test and demonstrate they can handle it? That is the biggest issues here: most folk don't have (or will pony up for) an NTP simulator to allow them to set up and test the OS/application reaction to these predictable and recurring events, so they simply hope for the best and, surprise, surprise, they get the worst!
-
Monday 23rd September 2013 08:26 GMT John Sager
Re: The UK's position
One of the problems is that, over decades, leap seconds will need to be added more often as the earth is slowly slowing, and the standard second is actually derived from the earth rotation rate sometime in the 19th century. However I think it is stupid to address this problem now. We can leave it to the boffins a century or so hence. Meantme there is Y2038 to get through...
-
-
Monday 23rd September 2013 08:26 GMT Schultz
Seconds? Give me hours!
“If leap seconds are eliminated from UTC, there will be no perceptible impact on social activities and conventions,”
Just as the Julian Calendar was just fine ... until it wasn't. I personally would favor omitting the switch to summer time ... to get one hour of extra sleep every year.
-
Monday 23rd September 2013 08:59 GMT Antony Riley
What is the fuss about?
"Sysadmins are among the groups inconvenienced by leap seconds, as while network time protocol (NTP) is aware of them and includes them in its updates, not every device is connected to an NTP server."
If hardware has neither a network time protocol nor an accurate time source, you'll have more than 1 second a year to worry about anyway. If you do have an accurate time source, then it'll be acting as your time server and you'll only have one box to update.
There are very few applications where you have many disconnected nodes which all have their own accurate clocks.
There is the small issue that applications can behave badly if the real time clock is modified underneath them. Normally NTP clients slowly adjust the RTC for any drift, which negates this issues, and even if it is an issue then the application is badly written and should be using the system clock for measuring the passage of time, instead of the RTC.
-
Monday 23rd September 2013 09:16 GMT alain williams
What a legacy we will leave
if we remove leap-seconds. OK: it probably will not have any real impact on my kids or grand kids, but as the centuries roll on the clocks will ever get more out of sync with that yellow thing upstairs. When they do come to fix it the problem will be huge: several hours to shift and computer systems which are based on the idea that there are always 86400 seconds in every day without exception.
I am sorry that the real world is more complicated than some would wish - but that is how it is.
Better to get used to it now than have our great, great, ... grandkids curse us for idleness.
-
Monday 23rd September 2013 09:43 GMT David Pollard
It's all French envy
Like earlier changes to abolish GMT, this proposal for temps atomique is mostly down to the politics of envy. The French and others have long been envious of Britain's naval history and hate to be reminded of our fine tradition by the Greenwhich in GMT.
Looking to the navy's 'aircraft carriers' though, it's a puzzle why they should need to bother.
-
Monday 23rd September 2013 09:47 GMT John H Woods
INSERT
“If PEOPLE WHO CAN'T UNDERSTAND leap seconds are eliminated from U̶T̶C̶ MAKING ANY DECISIONS OR POLICY WHATSOVER, there will be no perceptible impact on social activities and conventions ... but there will be significant reduction in the risk to national and international infrastructure and significant cost reduction in their implementation.”
-
Monday 23rd September 2013 10:46 GMT Paul Crawford
Another rant
Just to add to my already excessive comments here, the problem is not actually the leap seconds, it is the handling of time-steps by OS and/or applications.
Now if we eliminate leap seconds we still will have the occasional time-step in real systems, as someone monkeys with the clock, or a machine with a poor clock is forced to jump from time to time to keep up, or when a NTP server is blocked for several days due to a firewall or ISP fault then comes back on-line, etc.
In all of those cases, a time step will happen, and you have to deal with it or face problems. If the software developers DO NOT TEST for this, problems will happen. That was the lesson from last year's Linux bug. In fact, getting rid of leap seconds will mean even less testing and probably a BIGGER risk later when time steps happen for other reasons.
What happens if you don't test =>
-
Monday 23rd September 2013 13:03 GMT Anonymous Coward
Sysadmins...
... if a leap second is causing you problems because you're not connected up to NTP then accurate time keeping obviously isn't important to you anyway, so it really doesn't matter if we get an extra second on the end of a whole year as the chances are your clocks are out by way more then that anyway over the course of a year.
-
Monday 23rd September 2013 16:53 GMT another_vulture
IEEE 1588
When two computers need to synchronize absolute time to sub-microsecond accuracy, leap seconds become a big problem. There are a great many situations where this needed, especially in measurement systems for science and industry. These systems use 1EEE 1588 (a.k.a. PTP, Precision Time Protocol.) PTP used GPS time instead of UTC precisely to avoid leap seconds. See:
https://en.wikipedia.org/wiki/Precision_Time_Protocol
-
Tuesday 24th September 2013 07:20 GMT John Savard
The Time we Should Use
Obviously, the Internet and computers should run on civil time. And civil time should neither have leap seconds, nor go out of step with the Sun: so that means a second that is adjustable and slightly longer than an SI second.
Scientists and engineers can use UTC or TAI or atomic Ephemeris Time as they please, but the rest of us should use a system which continues to behave the way timekeeping did before its precision forced us to worry about leap seconds.
-
Wednesday 25th September 2013 10:30 GMT John 62
Re: The Time we Should Use
The principle of the leap second is that it's preferable to have one inserted every few years rather than adjust the length of the second, which would seem to be an incredibly difficult undertaking.
I'm not saying the leap second system is perfect, but I would prefer it to adjusting civil time. Currently the general populace doesn't have to care and only people who write date and time handling libraries have to.
Humanity copes reasonably well with the extra day added every 4 years (but not in a century year unless it is divisible by 400) despite the fact, that over a person's lifetime they probably wouldn't really notice if everyone ignored the leap year system and always had 365 year days. However, because we've had leap years for centuries so everyone has grown up learning about them in primary school and you have to make a leap year algorithm in maths or computing at secondary school. Leap seconds are relatively new, but if we start teaching people about them in secondary school, the concept will soon catch on.
-
-
Tuesday 24th September 2013 20:29 GMT sla29970
ITU-R links to last week's meeting
The links in the article are to a meeting that happened in Paris a year ago.
For last week's meeting in Geneva the main page is
http://www.itu.int/ITU-R/index.asp?category=conferences&rlink=itu-bipm-workshop-13&lang=en
all of the presentations are at
http://www.itu.int/oth/R0A0E000096/en
a press release by ITU-R is at
http://www.itu.int/net/pressoffice/press_releases/2013/Advisory-14.aspx
in depth articles by the participants are at
https://itunews.itu.int/en/