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.
Slow news day? Software dependent on accurate timing should be able to handle such exceptions such as leap seconds, leap years etc. It is a simple test case and is well documented. So if your software fails, you have a bug in your software, which shows you either didn't test or you're simply incompetent.
Also, most if not all languages have libraries that can handle accurate timing very well.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
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
As long at Netflix continues to work, everything else is secondary. What up with crackle making me use credentials to watch now? Uninstalled!!!
Aren't all the NTP servers subordinate to the Naval Observatory Clock anyway?
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.
Why would an airline, especially flight reservations, need sub-second synchronization between internal and external clocks (whatever they are)? That's got to be expensive maintaining that kind of synchronization.
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
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.
Perhaps the correct solution is to give up on servers being forced to agree on what time it is, and instead just agree on how many seconds it has been since some arbitrary date (i.e. UNIX time). As long as everyone counts the "ticks" together, it shouldn't make a difference, and may prevent software failure.
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.
If you feel that it is absolutely critical to increase Slashdot's presence in the social networking world in a big way, go ahead and add a share link. I get it. Expand or die. Join the bandwagon. If you don't have it, you're a 90's relic. Marketing department is very loudly demanding it and it's a quick and cheap way to shut them up. Great. There are lots of reasons for it. Fine.
But DON'T REMOVE STUFF THAT'S WORKING FOR YOUR READERS TO DO IT! Especially when there's enough screen real estate for both.
Also, it was mentioned elsewhere: We're here for the comments on the story, not just the story itself. Certainly not for the (often bad) summary. Let us share the whole story page, expanded with comments.
"Aren't all the NTP servers subordinate to the Naval Observatory Clock anyway?"
No.
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.
New Time Protocol Standard *Network Connected Sun Dial* install a Giant Sun Dial at Greenwich to continuously keep the internet in sync with the planets rotation.
Alternatively install a giant drive shafts and disk breaks at the poles to continuously adjust the earths rotation to keep it in sync with internet.
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.
So why even bother with this non sense?
Some drink at the fountain of knowledge. Others just gargle.
When you change a forum against the wishes of the users you risk the Digg effect. Please undo the "Share" change.
Seriously. There's no real advantage to keeping things tied to the solar day like this. Keep them separate. If you want to make adjustments, make them to the TZ rather than to the underlying time measurement. So, for example, EST would be adjusted to +1h1s from UTC.
I thought Slashdot was dead. I thought they killed the comments until someone told me where to look.
God spoke to me
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.
That's a leap minute....
But I know what you mean....
I like Google's idea better. I can't say why exactly, but it sounds cool.
We will all live underground in the future anyway. As it is I hardly get out to see the Sun now.
Look guys lets just forget this nonsense and let it ride until we are all extinct.
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.
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 was.
Fixed that for you.
Someone tell Nerval's Lobster that this week's "How Much [language] do you need to know for an entry level position?" identikit Dice article plug is overdue. I'm placing my bets that it's going to be ALGOL-58 this time round...
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.
Though I disagree about what "this nonsense" is. You seem to think the nonsense is having noon at midday.
I think the nonsense is the scaremongering about how bad it is that in June there will temporarily be a 1 second discrepancy between time recorded by two or more things using completely different clocks to measure the time.
Why bother with that nonsense? Why is "Yeah. So what? Live with it" not acceptable and throw out this nonsense that we should only recognise monotonically incrementing time everywhere everywhen every moment?
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.
do you run a super secret linux that lets you cron jobs by the second? http://www.adminschoice.com/crontab-quick-reference
Are you polling constantly for a specific time? Broken code in, bugs come out...
Sure, a leap second will throw off any timing measurements being done. But if you are barmy enough to program something that *dies* you just wrote a bug. There are all kinds of bugs, this one is not special.
What kind of website do you think Slashdot is?
I don't know if you've been following the news, but slashdotmedia owns sourcefourge, which has been doing some blatantly unethical thing to make money off of free software lately. Articles about this issue are being actively suppressed here on Slashdot.
Did you notice how there is a store now (deals?)
Slashdot is not the kind of website you think it is.
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.
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.
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
I would love to read more about the EIA Natural Gas Report trading, but don't see any more info in the article or in a google search. Did the computer traders parse the reports for keywords and determine instantly whether to buy or sell?
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
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.
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.
So rather than let the tz tools deal with this the way strftime's man page says it should, Google is going to deliberately pretend that June 30 is exactly 24 hours long, and they're going to deliberately make all timespan calculations that involve any part of June 30 be incorrect?
My first thought is, the folks at the Large Hadron Collider couldn't get away with this crap.
Good thing Google doesn't design any critical systems, like computer-driven automobiles!
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.
We don't have time machines nor, even if we invented them, the need to look at the timestamp of a file more than 6 months before it's written.
We only need to know the time of a file after the file exists.
Unless you're a TimeLord, in which case you won't be using NTP to sort out your tardis location system.
Amazon AWS could seize up and bring down half of the worlds IT infrastructure...
Say, isn't there some saying and 'bout eggs and baskets?
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
GPS satellites avoid the problem by distributing leapseconds separate from a continuous timescale (unlike the Russian GLONASS, which distributes Moscow time with all of its nasties). UTC without leapseconds is essentially terrestrial time (TT) (which is just a constant offset from international atomic time (TAI)). If all these systems that get disrupted with a second jump just stored TT with leapsecond separately, there would be no ambiguity.
I thought Slashdot was dead. I thought they killed the comments until someone told me where to look.
You're supposed to look from left (always), to right.
"...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.
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.
I prefer David's way. His method tells you the right time all the time
Google is intentionally telling you an incorrect time for as long as their trickle method is in place before the actual leap second. is done.
Absolutely correct. Special little snowflakes don't need to tinker when something not only works but is really liked.
I still use this: ?nobeta=1
If it weren't possible, I would remove the slashdot bookmark and be done with this site. I do use https://soylentnews.org/ too.
Share button is a joke. The above commenters nailed it. Take this advice.
F U if you don't.
For years (decades?) you've been able to click on the title to view the article. I didn't even realize the comment count was clickable. There's no UI indication that makes you want to click it. I though DICE was trying to remove redundant paths to the same page. Apparently I gave them too much credit and putting a Share button where Comment used to be is pure evil.
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."
The video section was bad enough!
Now silly share button and without the number of comments.
come on, Dice..
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.
Does the leap second happen globally, synchronously in all timezones (e.g. at 23:59:60 UTC and 00:59:60 CET), or exactly at each timezone's own 23:59:60 for each tz.?
Anyway, who cares, isn't every reasonable system supposed to use unixtime internally?
I am a Doctor... healthguideness.com provides you diferrent advices for your health fitness. It's all about health that how to make people healthy. Mens who want to make their sex power increase please you can ask me anything about this. I am always stand for you. Everytime i reply your questions and advise you about successful health.
Sex & Women
First, I read the headline. Then, I read the summary..... Now, I need to scroll back up to see how many comments or to click to view those comments.
I apreciate you are old-school, experianced slashdot reader and you never RTFA but we, new progressive DICE-generation, do not even read the summary so we wellcome the change and possibility to go right to comments without need to srcoll through boring summary.
The biggest non-issue ever - the problems are silly.
"Hours:minutes:seconds" is only a display issue - to which you may apply timezones or leap seconds or whatever. A leap second is really only the presentation timezones being shifted by one second.
For timestamps and synchronization, count seconds from some chosen startpoints - such as the common january 1. 1970. This count is unaffected by the solar day and its occational leap second.
Those who schedule "something" to happen at a certain time a certain day, really schedule it "x seconds from now". If they need to take leap seconds into account - well do that then. Leap seconds are published months in advance - plenty of time to fix software that currently doesn't cope well.
And don't do sillies like spreading the leap second out over a day. No need! I happened to be using my PC last time - the display went from xx:xx:59 to xx:xx:60 and that was fine with me. No problems whatsoever, and filesystem timestamps were in seconds since 1970 so my make job did not hiccup. Those with strict timing constraint should operate independent of "display time" anyway. They should schedule their precision events "x (micro)seconds from now" - a form of timekeeping that is not affected by someone slamming an extra second (or a complete leap day) into the clock/calendar system. We already handle leap days and months with different lengths - leap seconds are really merely "more of the same".
The whole thing is a non-issue blown out of proportion. Most systems don't need 1-second precision - I cannot understand why an airline system would be bothered by a 1-second drift. And those that need the precision, should avoid wall-clock time anyway.
Of course some software happens to be buggy - just fix it then. Don't invent strange ways of handling the leap second - just handle it. It is not hard - and you know what went wrong last time. It is still plenty of time for preparing for the next one - and then it won't be a problem again ever. Fix such bugs once and for all.
so how do I run my linux system with TAI instead of UTC?
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.
>>it's a question of whether your software was built with certain (I would say not unreasonable at first glance) assumptions
Yeah, like sony assuming that february always has 28 days. These simplifications do not work.
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?
"I just reply to you when I see you spamming Slashdot with your nonsense"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
1st: See subject dimwit & this quote from you agreeing w/ my points:
"I'm not denying all those things" - by dave420 (699308) on Wednesday September 17, 2014 @11:39AM (#47927435) FROM -> http://yro.slashdot.org/commen...
Of course you're not: It's impossible to dispute FACT on HOSTS FILES superiority to other methods!
(Since they're fact in favor of hosts doing more than so-called competitors & doing more with less for more security, speed, reliability, + anonymity online - which is, of course, more than a mere trolling stalking harassing "ne'er-do-well" like yourself could *EVER* manage).
---
"I'm simply pointing out that it takes an AdBlocker to block your spamming"- by dave420 (699308) on Friday June 19, 2015 @10:31AM (#49945047)
Then WHY DON'T YOU DO THAT, shithead? Answer that!
If you're "so-called 'better solutions'" are BETTER, & I bother you? Use them... OBVIOUSLY, asshole, you don't & you're just a "ne'er-do-well" troll, OR you have "other motivations" (see next):
(No, instead you stalk/harass me instead!)
* DO YOU WORK FOR AN ADVERTISING FIRM, or ARE YOU A WEBMASTER/WEBCODER, or ARE YOU A MALWARE MAKER, or ARE YOU AFFILIATED WITH 1 OF MY COMPETITORS?
Answer that too!
I'll be waiting (but you'll avoid every question, or lie - which only makes you look stupider than ever vs. myself)
(You must be involved with 1 of those above, especially since you're TOO STUPID to EVER "get the best of me" & you know it, witness the above - & their "so-called 'solutions' are INFERIOR TO MINE on TONS of levels, evidencing their stupidity in & of itself via inferior designwork!)
APK
P.S.=> SEE Dave420 SQUIRM everybody, lol - evasions galore from him to ensue are almost guaranteed... apk
As you aren't continually running NTP syncs every millisecond, engineer the systems to cope with a minor difference and correction via an occassional NTP sync, and the problems all go away.