Slashdot Mirror
June 30th Leap Second Could Trigger Unexpected Issues
dkatana writes: On January 31, 2013, approximately 400 milliseconds before the official release of the EIA Natural Gas Report, trading activity exploded in Natural Gas Futures. It is believed that was the result of some fast computer trading systems being programmed to act, and have a one-second advance access to the report. On June 30th a leap second will be added to the Network Time Protocol (NTP) to keep it synchronized with the slowly lengthening solar day. In this article, Charles Babcock gives a detailed account of the issues, and some disturbing possibilities: 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.
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 will use a different approach: Over a 20-hour period on June 30, Google will add 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.
But that could also be problematic. In adding a second to its NTP servers in 2005, Google ran into timekeeping problems on some of its widely distributed systems. The Mills sleight-of-hand was confusing to some of its clusters, as they fell out of synch with NTP time. Does Google's smear approach make more sense to you, or does Mills's idea of counting the last second twice work better? Do you have a better idea of how to handle this?
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 will use a different approach: Over a 20-hour period on June 30, Google will add 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.
But that could also be problematic. In adding a second to its NTP servers in 2005, Google ran into timekeeping problems on some of its widely distributed systems. The Mills sleight-of-hand was confusing to some of its clusters, as they fell out of synch with NTP time. Does Google's smear approach make more sense to you, or does Mills's idea of counting the last second twice work better? Do you have a better idea of how to handle this?
The only problem mentioned is that they fall out of sync with each other. If they're both otherwise fine, just pick one. Sounds like the disadvantages of either one aren't as big as the disadvantage of them not working well together.
Modern app appers app track of time using apps, not Luddite leap seconds!
Apps!
Typically when dealing with NTP you do not want big swings. In fact, a system using NTP that's too far out of sync, won't sync back up correctly. One that is slightly out of sync will slowly come back in sync over a period of time, hours or days even. Both approaches could work, they really could, but I think adding a few milliseconds here and there is a better way to get this done as long as the systems don't fall too far behind. I work with Avaya voice equipment and we've been warning people about this for months and months. We've provided instructions on several methods to ensure this doesn't cripple your system, but it all depends on how your NTP is setup. I also foresee issues with just adding an extra second to the day, this is not going to work for a bunch of systems and will actually throw them out of sync compared to googles approach. One of the solutions we've "provided" is to disable NTP shortly before the time roll over, then enable it once it's July. That's a pain in the butt, but if you can afford the few minutes of service interruption, it solves all of the issues right there, you turn it off when it's synced, turn it back on and it syncs to the new time. The real issues come in, for my field at least, with logging, this is going to throw a wrench into sys logs if it's not taken care of, and with some of the platforms, it will literally cripple the system.
Also, most if not all languages have libraries that can handle accurate timing very well.
I would consider t-SQL and *.NET pretty major languages, that completely fail to handle leap seconds.
But...it's not.
Because you have different approaches to it. If the community could agree on how to address the (growing) difference in time as measured by Earthborn measures with solar/Earth/rotation measures, then it would be. But, there are legitimate and valid disagreements with how time should be kept.
A problem for sysadmins is that the status quo of the standards requires that we choose which standard we want to violate. We can violate the specification of UTC by not counting 23:59:60 or we can violate POSIX by counting it or we can violate POSIX and the SI second by not actually keeping the system clock on UTC using smeared seconds that are not suitable for tracking projectiles and other real-time applications. This problem is old, 50 years old, as seen in the 3 plots on this web page.
A couple of nuke blasts on the moon would let us keep the Earth's rotation in sync with our atomic clocks. It's practice for asteroids, and good entertainment too!
I understand the desire to change things, but putting some social media Share link in place of the Read More link goes against the kind of website Slashdot is.
Please restore the original layout. Thanks.
Their method has a name in NTP parlance, it is called slew.
See man page ntpd(8).
-=/\- Jizzbug -/\=-
We have 600 machines in my company's network distributed over 20 cities in our country. The servers are all located on our main branch and are connected through slow WAN frame relay links (up to 4Mbps)
We have time differences between machines, sometimes up to 3 or 4 minutes, and we don't seem to have issues. I find it strange than a possible 1 second different could cause so much issues.
Perhaps the Google method is better because the adjustment will take place during the day and not at the last second.
Open Source Java Web Forum with LDAP authentication
That's not the problem.
Leap seconds are inserted by pretending that there's a 61st second in a minute. Everything not designed to handle that will fall flat on its face.
It's not a question of not knowing what time it is, it's a question of whether your software was built with certain (I would say not unreasonable at first glance) assumptions, or whether it follows the actual specification of the functions it uses and the data structures it handles.
58, 59, 60, 0, 1 tends to blow a lot of stuff up that was never built to handle such instances.
+1 - Mod parent up.
Linux (at least the kernel we run) handles a leap second as 23:58, 23:59, 23:59, 00:00. Code that has to do something specific at 23:59 then ends up doing it twice, unless you detect that and deal with it.
even if it means re-defining the second or decoupling official time measurements from planetary movement. Leap days, leap seconds, etc., are silly hacks that belong in a bygone era.
Help save the critically endangered Blue Iguana
Oh, excellent. Not only are the trains now running on time, they’re running on metric time. Remember this moment, people, eighty past two on April 47th, it’s the dawn of an enlightened Springfield.
Ignore it. How much does it impact humanity if the clock noon drifts a tiny bit from solar noon? We're looking at an impact of shifting noon by about a minute over the course of an average human's lifespan. The impact of ignoring it means that people who rely on sundials are left to solve the sync problem on their own, and that's a whole lot less of an impact than NTP.
Other systems that synchronize with natural phenomena, such as automated irrigation systems or automated lighting systems, can be adjusted by their owners.
If some purist insists that we have to fix it, let's agree to fix it once per century, and let the people 100 years from now figure out if it's important enough to them to worry about.
John
Name some languages that handle leap seconds properly.
I don't believe for a second (pardon the pun) that you've actually done this research and testing yourself.
At least it is just a second. That sudden extra hour of daylight in the spring is really bad for my rose bushes.
I'm an American. I love this country and the freedoms that we used to have.
There is exactly one correct way to do this.
2015-06-30T23:59:59
2015-06-30T23:59:60
2015-07-01T00:00:00
David Mills approach is not correct, but will generally work and limits the pain to 1 second.
Anything else is just stupid. We've only been doing this since 1972. You would think people would get with the program by now.
Anyone who's worked with time zones even a little bit knows that catastrophic failures aren't "unexpected" at all.
It doesn't exist.
The whole problem strikes me as one of human preferences, not technical requirements. There's absolutely no reason not to use our atomic clocks and just count number of seconds since some starting point. The desire to have the sun directly overhead at "noon" is a human one, divorced from any technical requirement. All of science, computing, networking, telecommunications, would be much happier if we didn't continually redefine time like this.
So let watch manufacturers and clock-app manufacturers deal with this, when reporting time for human consumption. It shouldn't be a problem for NIST and government bodies. NIST should instead be reporting Earth's orbital parameters as time delta from noon, as they change over time, not conflating time itself with Earth's orbital parameters.
This is the way GPS, Loran-C and TAI handle time, and it's the right thing to do.
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
I understand the desire to change things, but putting some social media Share link in place of the Read More link goes against the kind of website Slashdot is.
Please restore the original layout. Thanks.
+1 - Mod parent up.
+2. In a Slashdot comment, we must add links and formatting by typing HTML by hand. You would therefore think we know how to copy and paste a web address from Slashdot to Facebook, if that's what we really want to do. We don't need an icon to do it for us.
If you're going to add icons, switch the places for Share and Comments. Put the Share link to the right of the heading. Put the Comments link at the bottom. To me it seems more logical that way, it puts the Comments link back where it was.
"Aren't all the NTP servers subordinate to the Naval Observatory Clock anyway?"
No.
But...it's not.
Because you have different approaches to it. If the community could agree on how to address the (growing) difference in time as measured by Earthborn measures with solar/Earth/rotation measures, then it would be. But, there are legitimate and valid disagreements with how time should be kept.
Really? UTC is defined by International Telecommunications Union Recommendation (ITU-R TF.460-6), and it includes leap seconds. Do you have an alternative Telecommunications Union you abide by?
It's actually cheaper than trying to maintain only a loose synchronization. You just use prebuilt time equipment, which is almost always built for unnecessary precision, and have the service stop if the times are too far out of sync (indicating that a server stopped getting updates). If you have several servers in several sites, a single site losing its time service is not a big deal, as the service will fail over to the other sites. However, if none of your time clocks can handle the leap second, you'll lose all of your servers at the same time, as they all realize they aren't getting updates.
It's a hazard of having a uniform environment. Unfortunately, uniform environments are also far more cost-efficient to manage.
You do not have a moral or legal right to do absolutely anything you want.
Leap years and leap seconds are handled very differently.
The rules for leap years are according to a forumula that has been fixed for hundreds of years. Computers typically handle them as part of their conversion from internal "time elapsed since epoch" data formats to "human" date formats and otherwise don't care much about them. Even the simplified formula of "leap year every 4 years"
Leap seconds OTOH cannot be predicted in advance so you cannot realiablly convert "time elapsed since epoch including leap seconds" to "time elapsed since epoch excluding leap seconds" or "human datetime" for future datetimes and to do it for past datetimes requires an up to date list of leap seconds.
Then there is the problem that "time elapsed since epoch excluding leap seconds" which is a common way to represent time (presumablly due to the difficulty in converting "time elapsed since the epoch including leap seconds" to "human datetime" simply cannot correctly represent the times arround a leap second.
The testcase is also anything but simple, to test the code you have to inject fake leap seconds, but for a correct test leap seconds can only be injected at specific times (NTP for example increases it's update rate around possible leap seconds) so either you can only run the test at specific times or your entire test environment needs to run on "fake time". This is a big problem if your tests need to interact with a system outside the test environment in a way that depends on time within the test environment being in sync with time outside the test environment.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Blame posix for making all the goddamn pthread *_timedlock() calls take an absolute real time instead of a monotonic clock.
In anycase, I'm not even going to bother doing anything fancy. I'll let the system suddenly be one second off and then correct itself over the next hour. I'm certainly not going to do something stupid like letting the seconds field increment to 60. Having the ntp base time even go through these corrections is already dumb enough. Base time should be some absolute measure and leap seconds should just be adjusted after the fact in a manner similar to timezones.
-Matt
NTP would typically slew a 1-second difference, so Google is not out-of-line to add the second at the beginning of the day and slew their systems over the course of the day. Google uses lots of vector clocks in their distributed systems, they may have calculated that slewing over the course of the day introduces fewer time differences between machines than counting the final second twice (due to drift, which is inevitable on any NTP slave, corrected by "frequency discipline" and error estimates).
-=/\- Jizzbug -/\=-
That's not the problem.
Leap seconds are inserted by pretending that there's a 61st second in a minute.
Pretend, nothing. Those minutes do have a 61st second.
When you change a forum against the wishes of the users you risk the Digg effect. Please undo the "Share" change.
The ITU-R has outlined 4 methods for the future of UTC. Methods A1, A2, B, C1, C2, and D are from various delegations of the international assembly, and they are in serious disagreement with each other.
I thought Slashdot was dead. I thought they killed the comments until someone told me where to look.
God spoke to me
Even the simplified formula of "leap year every 4 years"
That should have said
Even the simplified formula of "leap year every 4 years" works for 1901 to 2099 which is from before the introduction of computers to beyond what most system designers would consider to be a reasonable system life.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
The ITU-R has outlined 4 methods for the future of UTC. Methods A1, A2, B, C1, C2, and D are from various delegations of the international assembly, and they are in serious disagreement with each other.
That's silly. There's no reason for it. Let's just sit down and come up with a new standardized method that covers all of these use cases.
#DeleteChrome
The way they changed the design is clickbait of sorts.
People trained their muscle memory to click that area to load more of the story or comments. Now they click and yell in frustration.
That's a really shitty way of luring people. Shame on you, Dice!
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
I understand the desire to change things, but putting some social media Share link in place of the Read More link goes against the kind of website Slashdot is.
Not only that, but even though they've added a new numeric post count inside of a little speech bubble... if you click on that, you don't get taken to the comments! You still get taken to the top of the page, and have to scroll down to get to the comments.
I realize Taco and the others are long gone, but doesn't anyone on the Slashdot staff even bother to look at the pages after a design change has been made?
#DeleteChrome
Those who write fragile code should be banished. The fact that so much software can't deal with time changes is very telling. It shows how stupid most software developers actually are.
I like Google's idea better. I can't say why exactly, but it sounds cool.
This is a troll?!
Is troll a synonym for insightful now?
"Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
My concern with allowing a second to happen twice is that time-scheduled events that just happen to coincide with that second might execute twice. Depending on the circumstances, the results could vary from unnoticeable to completely bizarre and damaging.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Perhaps I'm blissfully ignorant, but I don't understand why almost any software would need to be time synchronized down to the second.
Assuming there are applications where synchronized time is mission critical..... in those cases, relying on a 3rd party to provide time in a way you have no control over is PURE LUNACY.
The example of an airline grinding to a halt over 1 second..... I guess you do need highly synchronized computer systems so that you can tell me with 14 decimal places of precision that my flight is 20 minutes late.... Who the fuck built that system and said "Let's just sync it with time.nist.gov, because the government never screws anything up!"...?!
"Prediction: within 10 years, Windows will be a Linux distribution." Me, 7-6-2016
Why do we even bother with this? Why can't we just let noon move a second. Even after a hundred years it won't make any difference. Time zones on average vary in the suns position by a whole hour so a 1 sec variation of the solar zenith makes no difference. Anstronomers will still be able to find there stars.
Agreed. This is all nonsense. Even NIST admits that it's basically for legacy astronomical equipment. But any astronomer who needs real precision needs to deal with fractional-second corrections all the time now anyway, and there are published tables that allow one to do this. (For the current correction to convert from UTC to UT1, see here, which gives values accurate to +/-5 milliseconds.)
If we ever got maybe a minute or more off, I could possibly see the reason for a correction. But a second? Who cares? As I said, the very small number of people who actually need to use UT1 mostly do fractional-second conversions all the time anyway, as leap seconds aren't precise enough to keep up with the continuous variation.
The ITU-R has outlined 5 methods for the future of UTC [acma.gov.au]. Methods A1, A2, B, C1, C2, D, and E are from various delegations of the international assembly, and they are in serious disagreement with each other.
How about software developers stop relying on the notion of time being continuous? They could stop being lazy and actually implement algorithms that can handle discontinuous time.
Yeah, because that'll work.
Ditto. This is an awful change.
Instead of having a special case every few years, how about going ahead and making a millisecond of adjustment every day as needed? The adjustments could start with 0 or 1 milliseconds, and as the oceans slosh us ever slower, we could start making 1 or 2 millisecond adjustments every day at midnight.
Would also keep the stars better aligned to the official time.
The ITU-R has outlined 4 methods for the future of UTC
Only method A1(*) proposes to redefine UTC. All other methods are keeping UTC just as it is.
To sum up the methods :
A1: No more leap seconds, UTC will drift from UT1.
A2: Come up with a new name for "UTC without leap seconds" as the broadcast universal time, UTC becomes legacy.
B: Keep UTC as it is, also broadcast a TAI-based reference time on an equal basis.
C1: Keep UTC as it is, also broadcast a delta between UTC and TAI.
C2: Same as C1, with more verbose recommendations.
D: Keep UTC as it is.
(*) With A2, UTC is not broadcasted anymore, so it has the same implications as A1, but mbone was going with the definition of UTC, so there's room for nitpicking :)
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Not nonsense, time accuracy to milliseconds is indeed important in financial and database applications. More to the point, keeping systems in sync well enough for that is a long solved problem.
Seconded! The share button is something I will never use and the lack of the read more link makes the web page a lot hard to use. Hope you'll do the right thing and stop screwing with things for change sake. Stop trying to bring the beta site back!
Exactly, just as February may have 28 or 29 days, the 23:59 minute may have 60 or 61 seconds. If your software time system was not built this way, it is technically wrong.
Should they change the social media link back to "read more" all at once or should they do it a little bit at a time so that, for a few hours on the day they do the change-over, you will get to read a little bit of the article then go to a cut-down version of a social media site.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Take another look at Method D, which was just added in March: "No change to the Radio Regulations as the results of the studies are inconclusive." This is one group of delegations going on official record saying that all the effort expended by the ITU-R over the past 15 years has been worthless for making any decision to change the definition of UTC. That is serious disagreement.
1. The code I wrote worked fine. But we have to interoperate with other people's code that doesn't.
2. Any solution requiring programmers to write software properly is doomed to fail.
3. No-one, at the last leap second, thought that Linux servers would crash when they printed out a message indicating that a leap second would soon happen.
4. No-one, at the last leap second, thought their Java server software would go insane after a leap second because the internal timers stopped working.
The world is full of code that will break when a leap second happens.
Perhaps I'm blissfully ignorant, but I don't understand why almost any software would need to be time synchronized down to the second.
Yes, you are. Fart apps don't care about the time. The systems that let you sell your fart app to mobile users do.
Assuming there are applications where synchronized time is mission critical..... in those cases, relying on a 3rd party to provide time in a way you have no control over is PURE LUNACY.
Most of the world syncs to GPS, either directly using the time, or by using a frequency output that's synced to GPS. If you don't sync to GPS, you'll be out of sync with most of the world.
First off, the problem with leap seconds and unix is that unix time isn't UTC. Unix time is defined as seconds since epoch, ignoring leapseconds. Unix time is 'lossy' in that a the moment a leapsecond occurs can't be differentiated from the second before it. More information about that here: https://en.wikipedia.org/wiki/...
The problem is that POSIX.1 is plain stupid when it comes to leapsecond.
The correct solution to this problem would be as follows:
1. Fix POSIX.1 to define unix time as TAI.
2. Implement conversion routines i gettimeofday and other relevant functions.
3. Use a handy store for leapseconds.
Now, number 3 here is a bit tricky. Purists would probably want this in the TZ database or somesuch. This is well and good, but has the problem that the TZ files need to be packaged and updated on all the servers. If I remember correctly (please correct me if I'm wrong) Java is shipped with its own TZ files, and might also need them updated separately. Due to this, I think the most maintainable and portable way to do this across unixes would be to simply have an /etc/leapseconds file which lists the leapseconds since epoch. It does, however, depend on unix time being defined as TAI first.
"Rune Kristian Viken" - http://www.nwo.no - arca
The problem is systems which are poorly designed, and cannot properly handle leap seconds. That includes every POSIX system. Handling a leap second is fundamentally no different than handling a leap year. You have a minute with 61 seconds instead of 60, just like you have a month with 29 days instead of 28. But despite leap seconds existing since long before POSIX, the definers provided no means of enumerating a 61 second minute.
Counting the same second twice or changing the length of a second, both are doing it wrong.
"National Security is the chief cause of national insecurity." - Celine's First Law
What's nonsense is locking civil time to atomic time. There would be no need for leap seconds if civil time simply remained linked to astronomical time, as it was for millenia.
Oh, and NIST - at least the person responsible for the leap second file they distribute (Judah Levine) - really has a very poor understanding of how leap seconds work. He's actually stated that "In the legal definition of UTC, a leap second is "forgotten" once it happens." That is, of course, completely incorrect. No wonder NIST wants to drop them, they don't understand them.
"National Security is the chief cause of national insecurity." - Celine's First Law
Most, if not all of them. Unix time is leap second-ignorant and there are a number of other time sources that likewise handle leap seconds. If you do for some reason, require solar seconds or GPS time, there are other solutions for that. Most likely though, it's your platform that needs to handle the leap seconds and Linux, Mac, BSD, Solaris is more than capable of that, don't know about Windows or other esoteric systems though.
The issue is in human date/time representations and/or bad programming. I've seen many times programmers parsing a MM-DD-YYYY HH:mm:ss string rather than a proper timestamp. I've also seen programmers implement timers even in lower-level languages like C by simply subtracting "$current time" - "$past time" or having a timestamp with a "unique" requirement. If you've ever worked on platforms that do not keep accurate track of time or have no hardware clock such as embedded devices, virtual servers etc, then you know that it's a bad idea.
If you're relying on mm:ss to progress 'properly' during these time events, then you're in trouble. The article gives the example of timers as well which just gives me the heebie-jeebies.
Custom electronics and digital signage for your business: www.evcircuits.com
You can never assume that time will not change due to external factors. That could be due to a sysadmin executing the 'ntpdate' command, leap years, leap seconds or even daylight savings.
You're talking mainly about human representations of time though and although the conversion should be handled delicately, they should not be used for internal time representations (a major mistake I see very often is to handle/parse hh:mm:ss strings back and forth between a model and a controller).
The testcase however is one that does need handling though if you do require such reliance on time. It may not be simple but yes, it is possible to fake the clock (ntpdsim). External (live/production) data within a test environment is likewise a 'bad thing', you most likely will not handle outliers if you assume the current external data includes improper data.
Custom electronics and digital signage for your business: www.evcircuits.com
There have been 35 leap seconds in the past 42 years. In very round numbers, we could have....
1 leap millisecond 3 times per day,
1 leap second every year or so,
1 leap minute every 50 years or so,
1 leap hour every 3000 years or so.
Pick one, make sure your systems run against it. If you always use NTP sourced data, you cannot assume your GPS sourced data (or local nuclear clock data) will give you the same results.
Custom electronics and digital signage for your business: www.evcircuits.com
Keep in mind that the silliness of "leap seconds" is about the same as the silliness of "timezones". Both are involved with keeping the sun above our heads as we eat lunch.
.NET doesn't handle leap seconds because Windows doesn't. Its NTP client will ignore seconds values greater than 59, and then fix the time during the next update. This means that Windows can knowingly be up to a second off from UTC time between the introduction of a leap second and its next NTP update. This is important to know if you attempt a fully synchronous distributed system that relies on NTP for synchronization.
I'm willing to accept that layouts change and I'll need to look in a new place--but the new location is actually terrible usability. Here's why:
First, I read the headline. Then, I read the summary. I'm moving down the page, and I'm scrolling the page, too. So, now I'm at the end of the summary, and the headline for any story with a long summary is now out of the window. Now, I need to scroll back up to see how many comments or to click to view those comments. Extra work, even if the summary isn't long.
Fitts' Law applies here. They've made the target smaller in diameter, and placed it further away effectively. That means the difficulty of clicking to view comments is noticeably harder.
Chill out, dude. No one expected the UTC Inquisition.
I thought Slashdot was dead.
They haven't stopped trying.
Easy solution - add the extra second at 1 second after midnight on the last Sunday of June. No exchanges are open anywhere in the world at that time - so there's no advantage that 1 second gives anyone.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
Its been raised as an issue with radar trackers where the radar and the tracker have their own time sources and they slew at different rates. The tracker gets upset and drops tracks where the timestamp from the radar seems to jump by a second.
http://michaelsmith.id.au
Ya i seen that yesterday im like where the hell is the join conversation button. so i clicked the feedback button and sent in my unhappiness to them. I bet they are going to force us to the new Slashdot those of us who have been avoiding it with the nobeta tags
Jack of all trades,master of none
Agreed. In this case, the google answer is terrible because the answer for "what time is it?" is no longer the same. The other solutions stick a whole second at the time of departure, so the math is always consistent. With google's answer, 23:59:23 - 23:59:22 != 1 second. Ew.
I think you mean "atomic clock", not "nuclear clock", since the standards rely on the electronic transition frequency of atoms in standardized environmental conditions (e.g., temperature.)
I don't trust atoms -- they make up stuff.
"...the slowly lengthening solar day"
"Do you have a better idea of how to handle this?"
I do. Have everyone run west. This will transfer the force of their feet to the earth, causing it to rotate faster. Don't stop running or the earth will slow down again, wreaking the havoc described in the article.
Keeping systems in sync is the important thing. Keeping them so accurate, to second precision, with the solar day is practically useless for almost every real need. I mean, if we are going to be so arbitrary, why not choose millisecond precision, or microsecond precision?
No, what would be useful is coming up with a solid, well thought out, global plan for making this correction next century. Then implement that plan, moving around a minute or two, all at one time for all global systems in a predictable and deterministic way. None of this choosing to do it when and how you want.
(Oh, and get rid of daylight saving time and time zones while we're at it... kthx)
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Every single time a leap second comes up in the future, we have these panic-stricken articles predicting doom and gloom for some services.
If you haven't figured out how to deal with leap seconds that have been an issue since the '70s, I say your service DESERVES to crash and burn, and you DESERVE to spend long and stressful hours dealing with the mess.
Leap seconds aren't a surprise to ANYONE with a functioning brain cell.
I do not fail; I succeed at finding out what does not work.
> Pretend, nothing. Those minutes do have a 61st second.
Civil minutes may or may not have any correspondence with dictionary minutes. In the measurement of elapsed time intervals with more than one second of accuracy, dictionary minutes rule.
Leap years and leap seconds are handled very differently.
The rules for leap years are according to a forumula that has been fixed for hundreds of years. Computers typically handle them as part of their conversion from internal "time elapsed since epoch" data formats to "human" date formats and otherwise don't care much about them. Even the simplified formula of "leap year every 4 years"
You must have missed the Y2K boom.
Even after that, programmers STILL cannot handle leap years properly, and gave us a 1-day outage of the PS3-PSN login on 29 Feb 2012 when the PS3 tried to sync the time from PSN on login and don't understand the result.
Oliver.
People can't deal with leap seconds when they know they have to ... postponing it into one huge clusterfuck isn't going to improve matters.
Yes but that has absolutely nothing to do with my post.
Some drink at the fountain of knowledge. Others just gargle.
Take another look at Method D, which was just added in March: "No change to the Radio Regulations as the results of the studies are inconclusive." This is one group of delegations going on official record saying that all the effort expended by the ITU-R over the past 15 years has been worthless for making any decision to change the definition of UTC. That is serious disagreement.
This is a disagreement about future possible standards There is no disagreement about the current standard, which is why software that does not implement the current fracking standard is buggy.
Do you know why that did not happen?
Well, okay, it did not happen because some of us (most?) store the date as mm/dd/yyyy (here in the US) and not mm/dd/yy. You can display it anyhow you want - you can even display it in binary. How you store it matters. mm/dd/yy is a bad idea - even if you will be long gone by the time the company crosses 3000.
"So long and thanks for all the fish."
I thought the .NET NTP server was grabbed from the system default? If that is true - and you indicate it is not - then wouldn't changing to NIST NTP work? Also - can one not change (I have never had a reason to even look into this) .NET to NIST?
"So long and thanks for all the fish."
reading this gives me a bad feeling that my night might suck. My job is intimately involved with multiple airlines, real-time systems, mainframes, etc. So I'm sitting on top of a network that might actually be affected. I haven't heard a peep of this from my management either...I doubt they even realize this is going on or that it may impact us.
Another relatively common use case is version control systems. They rely, at least in party, on accurate time stamps to resolve check-out and -in conflicts. Especially if multiple developers are working across a WAN or in the cloud, those timestamps would be fairly important. And--I'm speculating outside my area of expertise-- wouldn't there be a serious security vulnerability with a time discrepancy on mission-critical systems? A way to insert malicious code in that gap?
So, yah, this is probably very important.
Do you have a single example of a version control system that uses time to handle conflicts? I have never seen a system doing that, they all just handle it by looking at which commit reached the server first.
Ok, so if more often is better, how about leap milliseconds? Adding a leap millisecond every day would almost precisely mimic the average rate of leap seconds... to the point of being off by less than one second every century. It would be regular enough to become a standard, so all devices that need such precision would be updated to take it into account.
In any case, leap seconds are a bad implementation... they occur so often that they cause regular synchronization issues, and they don't occur often enough as to force those with a stake to come up with a standard solution.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
I care about these things. It seems like some other people do too.
The solution is, of course, "international agreement" on how to handle the issue. Does not matter which approach, so long as everyone agrees on it. Good luck with that one.
Sent from my ASR33 using ASCII
Unfortunately. 90% of the world uses an unreasonable system: "Windows". and 1% is out to exploit this f@$# up.
Sent from my ASR33 using ASCII
People can't deal with leap seconds when they know they have to ... postponing it into one huge clusterfuck isn't going to improve matters.
Well, I don't know... we manage with a whole leap day every four years or so.
so how do I run my linux system with TAI instead of UTC?
I get a strong urge to slap programmers who use the simplified evenly divisible by four rule to calculate leap years. It just so happens that 2000 was the 1 in 400 XX00 year that is a leap year so it works a couple of decades either way. The problems start when your code is applied to a longer or historical data set. This can happen when you don't have full knowledge of how your code is going to be used or just when you fall into your old bad habit of ignoring the function for your simple and wrong divisible by four rule and don't even see the problem coming, Symptoms include days of the week out of sync, computations involving date/time functions and the hand rolled divisible by four rule start to give odd results, your monthly and yearly averages are out, that very pretty graph dives from a narrow range in the thousands to zero at the end of February 1900, throwing the whole graph out of scale, and you get to find out how graciously or otherwise your system handles being asked about a date that doesn't exist, or if you're really, really lucky like I was - all of the above. I don't know who wrote the wretched code but I had to fix it. Most languages have a decent set of date/time functions - use them unless you have a really good reason not to.
Right so, as I said. Don't change the clocks at all. so no problem. THere is no need to change the clocks. SO the sun is off by 1 sec in the sky. this does not affect time on earth.
Some drink at the fountain of knowledge. Others just gargle.
What's nonsense is locking civil time to atomic time. There would be no need for leap seconds if civil time simply remained linked to astronomical time, as it was for millenia.
Sorry, but what the heck are you talking about? Your "solution" makes no sense given the need for accurate timekeeping today. Astronomical time varies significantly with the earth's rotation all the time by various amounts of milliseconds (see here for an illustration of that variance since modern UTC standards were adopted).
The "length of a day" is simply nowhere near precise enough for modern applications. It worked to lock civil time to astronomical time when an error of a few milliseconds here and there wouldn't make a difference -- you could just reset all your clocks. But now much of our timekeeping software dealing with civil time works on machines where a few milliseconds here and there will screw things up all over the place.
Are you at all aware of the mess things were before the modern UTC standards were adopted? They tried to make corrections on an order of milliseconds on a regular basis, and it was annoying as all hell. That's why they proposed only altering the standard clocks when the collective error accumulated to closer to a second -- the shift could then easily take place.
What exactly do you think you're proposing here? That seconds will just be arbitrary lengths for civil time, varying on a daily or weekly basis to track the earth's variance in rotation? Or we keep the second constant, but that we make daily or weekly corrections somehow? Or what?
Modern technology needs civil time to be consistent. And it needs to be precise because there are far to many machines which depend on it not varying by random little increments all the time. There are various ways of solving this problem, but just waving your hands and getting out your sundial to mark noon every day (as they did for millennia) is simply not possible in the modern world.
People who need sub-second accurate time use TAI. Civil needs would be met just fine by a return to GMT, instead of UTC.
"National Security is the chief cause of national insecurity." - Celine's First Law
The thing that people-who-don't-know-better are suggesting is that the second will be the same all the time.
They think that nothing bad will come from "thirty years from now, the sun is in the south at 11:59:30" (assuming an average of 1 leap-second per year).
(I can't think of anything bad that would happen... but I know my limitations. It's probably annoying as hell to /some/ fields of research or something....)
The article claims that NTP is the cause of the leap second. NTP is just a protocol that handles keeping computer clocks in sync with each other and with the official time (UTC, IIRC).
If NTP handles leap seconds by increasing update frequency and then coming to the conclusion: "Whoa! my offset just went from 0.3 ms to 1000.25 ms, lets step the clock a second once we're sure this was not a fluke measurement". then that's a bad way of handling it in my opinion. (also suddenly speeding up does not provide a smooth-enough transition).
One of the things that is bad about this is that when normal operation can handle (the bandwidth of) most hosts updating every 1024 seconds, and a few hosts (just rebooted, just installed, sync lost, whatever), now all of a sudden a synchronized (pun intended!) attack will take place where many many hosts will increase their update frequency by several order-2 magnitudes.
For google, they internally have needs for synchronized clocks. Why I don't know, and I don't care. They have decided to handle the leap second in a more controlled way. It's actually not that hard. Just make sure that everything syncs off one level-0 server, and during the 20 hour period leading up to the leap second, add a variable number of microseconds to the exported time.
nothing arbitrary about it, compliance auditing for various standards exists already. you are complaining about a solved problem and a standard way of keeping time.
I'm sorry, I don't understand what any of that has to do with synchronization with solar time (which is the point of leap seconds). You'll need to provide more info.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
For several months I have been checking on the on the official LHC schedule:
https://espace.cern.ch/be-dep/...
and had been wondering about the notation "leap second" on the Wednesday of week 27 of 2015. This posting now makes me understand what is going on. I can imagine lots of consequences for the both the machine (think of how far in the lab frame a 7.5 TeV proton goes in 1 s) and the enormous (at least enormous if you aren't Amazon, Apple, Google, or Microsoft) pile of HTC servers on 6 continents we use to reduce the data into Nobel prizes (hopefully prizes plural...).
Fred
You don't remember it because it was one of the largest mobilisations and tasking of programmers the world has ever seen. If nothing was done, there would have been massive problems throughout every computerised industry, as all kinds of bugs were identified and fixed. I was there - were you?