IoT
IoT
Software // Information Management
News
6/17/2015
10:06 AM
Connect Directly
Twitter
RSS
E-Mail
100%
0%
RELATED EVENTS
Core System Testing: How to Achieve Success
Oct 06, 2016
Property and Casualty Insurers have been investing in modernizing their core systems to provide fl ...Read More>>

'Leap Second' Clocks In On June 30

It doesn't sound like a big deal, but every second counts in the Network Time Protocol upon which the Internet and all apps that synch with it are based.

7 Data Center Disasters You'll Never See Coming
7 Data Center Disasters You'll Never See Coming
(Click image for larger view and slideshow.)

At the end of June, a rare event will occur. Due to a barely discernible slowing of the Earth's rotation, a leap second will be added to the Network Time Protocol (NTP) to keep it synchronized with the slowly lengthening solar day.

That might seem like a simple thing to do, but as John Engates, CTO at Rackspace, said when asked about keeping computer clocks synchronized: "Time gets complicated fast." Not everyone will add the leap second in the same way, or at same time. Some organizations, including Google, will do it their own way.

In fact, as you stick with us through this article, you may be longing for Morgan Freeman to step in and break it down for you, as he does for the Science Channel series Through the Wormhole. We can't give you Freeman, but we can give you all you need to know about why the leap second really matters to IT.

The original author of the NTP protocol, Prof. David Mills at the University of Delaware, set a direct and simple way to add the second: Count the last second of June 30 twice, using a special notation on the second count for the record.

Google has divined what it calls a "clever" way to do it, adding bits of a second throughout the day on June 30, so that there's no jarring last-second adjustment to clocks. It calls its method the "Google Smear."

(Image: Geralt via Pixabay)

(Image: Geralt via Pixabay)

"We have a clever way of handling leap seconds," wrote Google site reliability engineers Noah Maxwell and Michael Rothwell in a blog posted May 21. "Instead of repeating a second, we 'smear' away the extra second." Over a 20-hour period on June 30, Google adds a couple of milliseconds to each of its NTP servers' updates. By the end of the day, a full second has been added. As the NTP protocol and Google timekeepers enter the first second of July, their methods may differ, but they both agree on the time.

[ Does anybody really know what time it is? This guy does. Read NTP's Fate Hinges On Father Time. ]

Traditionalists -- some might call them purists -- like Harlan Stenn, chief maintainer of the Network Time Protocol, don't like the smear. "At noon on June 30, clocks (of smear implementers) will be off by a half second," he said in a February interview with InformationWeek about the intricacies of computer timekeeping. That's a lot in terms of precision time -- it might as well be a decade.

As the day wears on, processes based on precise timing -- such as the amount of time a valve opens to add a chemical to a mix -- will be off by more than a half-second if they relied on the Google smear. "What if you're getting radiation treatment? Do you want your radiation dose to be off by a half-second or more?" asked Stenn.

Why Every Second Really Counts

The last time a second needed to be added to the day was on June 30, 2012. For Qantas Airlines in Australia, it was a memorable event. Its systems, including flight reservations, went down for two hours as internal system clocks fell out of synch with external clocks. Prior to 2012, a second was added on Dec. 31, 2008, and also in 2005. The process started in 1972, and we'll have made a total of 36 additions by the end of the day on June 30, 2015.

There are agencies that are good at measuring the solar day, such as the US Naval Observatory in Washington and the Royal Observatory in Greenwich, UK. They dictate when the need to add a second arises. But no one supervises how the addition is made to all computer systems.

NTP does it in the way that it does because it's coordinating millions of computers based on the Posix standard, a 1989 relic that was meant to resolve differences between various Unix brands. Linux and Windows have since adopted Posix standards. Posix dictates that there are exactly 86,400 seconds in the day, every day, no more, no less. To simply add a second to June 30, and count it accurately in NTP, would throw the count permanently out of synch for all Posix-based computers relying on NTP time servers.

Next Page: 86,400 Seconds Every Day

 

Charles Babcock is an editor-at-large for InformationWeek and author of Management Strategies for the Cloud Revolution, a McGraw-Hill book. He is the former editor-in-chief of Digital News, former software editor of Computerworld and former technology editor of Interactive ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
nomii
50%
50%
nomii,
User Rank: Ninja
6/27/2015 | 10:54:07 AM
Re: Seriously.... I hope no one is being paid to figure this out!
@Linux I agree with you. In my opinion it might not be a big problem for some but for those who are calculating thing in smaller fractions of time it might give them sleepless nights. :) I am not sure this kind of smaller fraction will affect most of the people. So its better to leave these problems aside and concentrate on bigger issues first.
hstenn
50%
50%
hstenn,
User Rank: Apprentice
6/26/2015 | 3:24:26 AM
NTP doesn't care what time scale you use.
Normally, NTP will keep the system clock in correct POSIX time because that's what the POSIX standard requres.

NTP  is perfectly happy keeping a system running GPS time, which has no leap seconds.

NTP is also perfectly happy keeping clocks synchronized that track Martian Standard Time, in which a day on Mars is about 39 minutes' longer than the day on Earth.

NTP isn't the problem.  Leap seconds don't cause problems.  The problem is Standards that do an inadequate and incomplete job of addressing the realities of the timescale they choose to use, and/or systems that specify which timescale they are using without fully understanding the scope of their decision.

Screwdrivers come in different shapes and sizes.  For good reasons.

This same attitude and behavior that caused these problems can be seen in some of the other comments here.  "It's not a problem for me.  I don't care what your problems are, because they're not (yet) my problems."

As soon as the NRA figures this out I expect they'll want to send Network Time Foundation plenty of money, as you just know that if they start coming after "our" leap seconds, you just know what they'll be coming after next.

I'm not suggesting that we require UTC for computers.  I'm not suggesting we use TAI or some other timescale for computers.

I am suggesting that if Network Time Foundation can get properly funded so it can put adequate resources towards solving these problem then we'll all be better off.  This includes development and maintenance of NTP and other network-time related projects, including the General Timestamp API.
RobSeaman
50%
50%
RobSeaman,
User Rank: Apprentice
6/24/2015 | 2:35:37 PM
Requirements for UTC and Civil Timekeeping on Earth
Interested readers can find more about leap seconds than they might have believed possible from the proceedings of two workshops held in 2011 and 2013 on the future of Coordinated Universal Time. Search on "Requirements for UTC and Civil Timekeeping on Earth" (URLs are not permitted in comments). A feisty if small community has been debating these issues for many years.

The fundamental tension that creates the need for leap seconds comes from the fact that atomic time and solar time are simply two different things. Mean solar time arises from the "synodic" day. The sidereal rotation of the Earth (relative to the stars) has small variations and a general slowing trend due to lunar tides. As we lap the Sun once per year, one rotation is unwrapped, and as a result there is one fewer day per year than sidereal rotations. While the solar clock subdivides calendar days, atomic clocks are metronomes in multiples or fractions of seconds, or better yet in units of frequency, Hertz. Solar time counts fractions of days and atomic time, multiples of SI seconds; there is not a fixed relationship between solar days and SI seconds. Wishing it will not make it so.

One somewhat bizarre result is that if leap seconds cease, the Prime Meridian will begin to move from Greenwich, England to Paris, France at a rate of about one football field (American or European) per year.  Presumably this won't actually happen but nobody has offered any explanation of what will have to change to avoid such an issue. In fact some are relying on schemes to hide the embargoed leap seconds within the standard timezone system whose origin is the Prime Meridian.

While timekeeping issues at the level of seconds may be negligible for some purposes, they are quite significant for fields like aerospace, astronomy and navigation. Navigation these days means in the air and on land as well as at sea; GPS and other GNSS satellites themselves depend on solar time to operate. Ceasing leap seconds is a very expensive proposition for many communities, and a risky one for others that have not previously considered a distinction to exist between solar and atomic clocks.

- Rob Seaman, National Optical Astronomy Observatory
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
6/24/2015 | 2:22:09 PM
Forget lattitude, just use attitude
"Seriously, could this really be a problem that had to be corrected. LinuxGuy-VPK" If you detach time from the solar day, then you have to start making adjustments in longitude and navigation. Longitude zero or the prime meridian runs through Greenwich, England, and for centuries, travelers have gauged where they are in the world based on the amount of time they've traveled at what speed and maps using lattitude and longitude. If we ignore the solar day, then the prime meridian has to start migrating from Greenwich toward Paris at the rate of a football field a year. This isn't a problem for LinuxGuy, who would dispense with all that longitude and lattitude hocus pocus and just use attitude. (Tip of the hat to Rob Seaman, data engineer at the National Optical Astronomy Observatory, who pointed this out.)
sebk@google.com
100%
0%
sebk@google.com,
User Rank: Apprentice
6/19/2015 | 7:18:02 PM
Re: The solar day makes sense to a lot of humanity, historically speaking
We have timezones with typically (there are few exceptions) 1h granularity. And there is daylight saving time moving time zone 1h further East for roughly half of the time (typically more than half). And many time zones are still significanly off solar time (so much off that in many countries there is no agreement with local solar anywherein the zone). IOW in some places the officlal time is >3h off the local solar one.

Those who need precize synchrnization with solar time need correct ephemerides anway. BTW which solar time? Avarage solar time or actual one? And if average then which average? As Earth orbit is not exactly circular actual noon and midnight points shift around during a year, and this shift is significantly more that a few seconds).

So, no, we generally don't care for seconds level accuracy of officlal time vs solar time.  And where we (very rarely) do we already use proper mechanisms for that.

Leap seconds just expose hard to find bugs and make time keeping unnecassarily more complicated. What if your radiation therapy is being done on late June 30th evening?

Actually i'd prefer smeared time for my radiation dosage -- if irradiation lasted just 72s then with smear my dosage error would be 1ms or 0.0014%. OTOH with leap it might get 1s longer or 1.4% -- this is 1000 times more! With even shorter therapy (like 7.2s) doese would be 14% off with leap while error would stay 0.0014% with smear. Error perecentages get equal when radation dose is meant to be delivered over 20h - then in both cases the error is 0.0014%. 

So, what's the gain for all the cost?

GPS designers made the right call - they completely ingnore leap seconds. If you use GPS as your time source you may either allow for your time being rougly half a minute off the official one or use actual translation tables.

NTP would be better off if it went GPS way. Stuff like leap seconds should be handled similar to time zones. If some country edcides on a leaps second then we just update zone tables. But actual clock should just count seconds.
Gigi3
100%
0%
Gigi3,
User Rank: Ninja
6/18/2015 | 11:56:56 PM
Adding a second for Synch
""Instead of repeating a second, we 'smear' away the extra second." Over a 20-hour period on June 30, Google adds a couple of milliseconds to each of its NTP servers' updates. By the end of the day, a full second has been added. As the NTP protocol and Google timekeepers enter the first second of July, their methods may differ, but they both agree on the time."

Charlie, in my opinion adding a second by end of the day or adding certain mille second on every hour are same. In both cases, at the end of the day one second is get added for synchronization.
Gigi3
100%
0%
Gigi3,
User Rank: Ninja
6/18/2015 | 11:55:10 PM
Adding a second for syncronization
""Instead of repeating a second, we 'smear' away the extra second." Over a 20-hour period on June 30, Google adds a couple of milliseconds to each of its NTP servers' updates. By the end of the day, a full second has been added. As the NTP protocol and Google timekeepers enter the first second of July, their methods may differ, but they both agree on the time."

Charlie, in my opinion adding a second by end of the day or adding certain mille second on every hour are same. In both cases, at the end of the day one second is get added for synchronization.
Charlie Babcock
0%
100%
Charlie Babcock,
User Rank: Author
6/18/2015 | 1:14:31 PM
The solar day makes sense to a lot of humanity, historically speaking
LinuxGuy, I have to disagree. Precise time-keeping originally had to do with navigating oceans in saling ships. Pendumlum based clocks for time-keeping didn't work, due to the rocking motion of the ship. And surely you're familiar with the difficulties of determining latitude and longitude using a sextant. You have to precisely capture the angle of the moon or a star to the horizon... oh nevermind. Noon and midnight need to be fixed points in the day against which other time processes can be aligned. To have different parties moving them around, depending on whether they wish to observe solar time or not makes no sense to most of humanity.
LinuxGuy-VPK
100%
0%
LinuxGuy-VPK,
User Rank: Strategist
6/18/2015 | 10:06:48 AM
Seriously.... I hope no one is being paid to figure this out!
So in the Past 43 years, the clock has had to be adjusted by 36 seconds... hmmmm, Oh the horror.

Seriously, could this really be a problem that had to be corrected.... I understand daylight savings time to keep our daylight in time with our usual working hours, and leap year to account for the extra 1/4 day per year every 4 years (which it seems is a result of a simlar cause - rotation around the sun, versus rotation of the earth itself on it's axis).

Based on these numbers it would take us 4,300 years to lose an hour, or 103,200 years to lose a day.  Why not just leave it alone?  Computers don't care what specific time of day it is (night/morning/etc.) just the actual time... so why bother correctly for it at all!

Finding solutions for problems that just don't matter, if you ask me.
tmeehan532
100%
0%
tmeehan532,
User Rank: Strategist
6/18/2015 | 10:03:34 AM
Stop using solar time?
Impractical as it sounds, machines need to stop using solar time.  The problem is that solar time increments vary in length.  Machines don't care about solar time, they care about consistent increments of time.  So why do we force them to use solar time?

Oh yeah, noon must always fall when the sun is at its zenith in the sky.  We all know how important that is to us humans.  It's also why we have time zones and daylight savings time, more things machines don't care about but are forced to contend with as politicians change them.

 

 
Page 1 / 2   >   >>
The Agile Archive
The Agile Archive
When it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.