'Leap Second' Clocks In On June 30 - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Comments
'Leap Second' Clocks In On June 30
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%
[email protected],
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 State of Cloud Computing - Fall 2020
The State of Cloud Computing - Fall 2020
Download this report to compare how cloud usage and spending patterns have changed in 2020, and how respondents think they'll evolve over the next two years.
Commentary
CIOs Face Decisions on Remote Work for Post-Pandemic Future
Joao-Pierre S. Ruth, Senior Writer,  2/19/2021
Slideshows
11 Ways DevOps Is Evolving
Lisa Morgan, Freelance Writer,  2/18/2021
News
CRM Trends 2021: How the Pandemic Altered Customer Behavior Forever
Jessica Davis, Senior Editor, Enterprise Apps,  2/18/2021
Register for InformationWeek Newsletters
Video
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
White Papers
Slideshows
Twitter Feed
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.
Sponsored Video
Flash Poll