June 30th Leap Second Could Trigger Unexpected Issues 233
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?
Doesn't matter (Score:5, Informative)
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.
Re: (Score:3, Interesting)
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 [nist.gov] 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 [nist.gov], 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
Re: (Score:2, Insightful)
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 want
Re: (Score:3)
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 [wikimedia.org] 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
Re: (Score:2)
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.
Google is right (Score:5, Interesting)
their approach is called: SLEW (Score:2)
Their method has a name in NTP parlance, it is called slew.
See man page ntpd(8).
Re: (Score:2)
"Typically when dealing with NTP you do not want big swings."
A second is not a "big swing" in general computation parlance. People working on near-RT systems already know -or should know, how to cope with leap seconds.
"In fact, a system using NTP that's too far out of sync, won't sync back up correctly."
Five to fifteen seconds at least. We are talking a different league, almost a different sport here.
"I work with Avaya voice equipment and we've been warning people about this for months and months. We've p
Re: (Score:2)
People working on near-RT systems already know -or should know, how to cope with leap seconds.
Hey, guess what, those guys they outsourced the software development to in the third world... don't. And they know they'll have moved on to a new job by the time the next leap second happens.
The rest of us have to deal with their hardware not doing what it's supposed to when the leap second hits.
1s > 128ms, therefore slew (Score:2)
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).
Re: (Score:3)
Typically when dealing with NTP you do not want big swings.
This is a solved problem, though (sibling points out the reason why: slew.) In practice, this is also a known conditions, especially with virtual machines (doubly so with VMWare-hosted VMs [virtualizationadmin.com]). This is because VM's time-slice the physical CPU, so the keeping time on the VM's OS clock is very imperfect anyway.
Google is wrong. (Score:2)
Counting the same second twice or changing the length of a second, both are do
choose what standard to violate (Score:5, Informative)
Re:choose what standard to violate (Score:4, Insightful)
If the POSIX standards people had bothered to actually follow the existing SI and ITU standards back in 1988 when they were setting up their standard, this would not be an issue.
Re: (Score:3)
one of the links from that page talks about how using custom timezone files you can use non-leap seconds and still translate to accurate real-world values. I'm not terribly familiar with time keeping protocols; installing ntp and pointing it at a server is about as far as I can manage. Do you see a problem with the approach laid out at "Correct precision handling of leap seconds using code already on POSIX systems " [ucolick.org]?
Dice: Please restore the Read More link. Thanks. (Score:5, Insightful)
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.
Re:Dice: Please restore the Read More link. Thanks (Score:5, Informative)
+1 - Mod parent up.
Re:Dice: Please restore the Read More link. Thanks (Score:5, Insightful)
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.
Re:Dice: Please restore the Read More link. Thanks (Score:5, Insightful)
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!
Re:Dice: Please restore the Read More link. Thanks (Score:5, Interesting)
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 [wikipedia.org] 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.
Re:Dice: Please restore the Read More link. Thanks (Score:5, Informative)
Re: (Score:3)
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?
Re: (Score:2)
Ditto. This is an awful change.
Re: (Score:2)
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!
Sync (Score:4, Informative)
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.
Re:Sync (Score:5, Informative)
I find it strange than a possible 1 second different could cause so much issues.
It's not the time difference that causes problems per se, it's time going backwards. You presumably missed the fact that many Java servers crashed over the last leap second because of a kernel bug that screwed up their internal timers?
We had problems last time due to faults reported by external hardware when it saw the time jump backwards. I'll be at my desk when it happens this time to deal with any problems that come up this time.
And, given the chaos every leap second causes, hopefully we can finally convince the 'experts' to stop fiddling with time.
Re: (Score:2)
This.
With the exception of highly precise equipment, if your systems crash & burn because of 1 second differences, you're doing something wrong.
Re: (Score:2)
If you've got equipment that needs such high precision and you're synchronizing it with NTP rather than an internal standard, you're doing something wrong.
Re: (Score:2)
Agreed. Slew is acceptable in using NTP. Slew is often more than 1 second.
Re: (Score:2)
Agreed. Slew is acceptable in using NTP. Slew is often more than 1 second.
If I remember correctly, NTP has a leap-second flag which indicates that the time should jump by a second at midnight. It doesn't slew, at least on Linux... otherwise different machines would be reporting different times until they'd all slewed back to what they should be.
Re: (Score:3)
Slew can be used in NTP for any clock adjustment, not just leap seconds. Linux does use slew (as opposed to step) to make clock adjustments. In the special case of leap seconds, it uses step, rather than slew.
Re: (Score:2)
I believe the proper phrase would be CAN use slew. Its actually a command line option on startup of ntp.
I only know this because a particular piece of software I have had to install requires it and will refuse to install if its not set.
Re:Sync (Score:5, Informative)
I'm not sure exactly what arguments each Linux distribution uses, but this is from the man page on ntpd:
My reading of that is that the normal adjustment uses slew. Step is used only when there's a big discrepancy, and you can use -x to use slew even in that case.
Re: (Score:2)
With the exception of highly precise equipment
It's not like I wrote a huge wall of text...
Re: (Score:3)
Re: (Score:2)
Similarly, a five-minute offset will prohibit logins and group policy updates. If your Windows Time Service configuration is pushed via group policy, you're kinda screwed, and you'll need to have a local admin on site to nudge the clock in the right direction.
Re: (Score:3)
We experience this issues when the motherboard battery dies and resets the computer's date to year 2000 or such. Since most users aren't admins, the machines can't receive the correct time on their accounts therefore we logon with our admin accounts and the time corrects itself.
But for 3-4 minutes we don't have issues.
Re: (Score:2)
Re: (Score:2)
5 minutes? That is nothing, we had a bug in one of our builds were we forgot to set hardware clock. Turns out our blade vendor was sending us systems with the clock set years in the past, so after build, the system would boot with hardware time, refuse to sync the clock due to the enormous skew, and then refuse logins because..... our ldap ssl certificates were not YET valid!
We need a long-term solution (Score:4, Funny)
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.
Re: (Score:2)
We have at least three of them. GPS, LORAN and TAI standards do not include leap seconds. They drift ahead of UTC, but they're designed for applications that need good synchronization without having to worry about things like leap seconds. UTC is designed so that the sun will always be up during the day and down at night.
If synchronization is what you want, use one of the standards designed for it.
Re: (Score:2)
UTC is designed so that the sun will always be up during the day and down at night.
There have been 25 leap seconds since 1972. At that rate, it will take around 6000 years for UTC to be even an hour different from TAI. Leap seconds don't have any appreciable impact on the sun always being up during the day.
I don't think anyone really cares about whether we use UTC or some other system, though. The problem is that software/hardware vendors have all been using the wrong time standard -- nobody but astronomers actually has a reason to want UTC. We just need to get developers to use a dif
Re: (Score:2)
*always* be up during the day.
If you think a leap second is a pain, you should try switching to a new calendar. Some people can actually think past the next quarterly report.
Personally, I think leap seconds are a great idea because they expose shoddily made software and hardware. If you (think you) need sub-second synchronization and just tossed in an NTP server instead of implementing a proper synchronization mechanism, you likely cut corners somewhere else too.
Re: (Score:2)
If you think a leap second is a pain, you should try switching to a new calendar. Some people can actually think past the next quarterly report.
There's a difference between not looking past the next quarterly report, and not worrying about a completely unrealistic scenario -- in this case, that my software will still be running 50,000 years from now when there actually is a disagreement in date between UTC and another standard.
Personally, I think leap seconds are a great idea because they expose shoddily made software and hardware.
Introducing pointless complexity to try to "catch" poor software or hardware is a bad idea. Engineering is a hard enough job without purposefully making it harder.
Re: (Score:2)
Metric time (Score:2)
We should do what GPS does (Score:2)
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
Re: (Score:3)
I recently took a private tour of the time and frequency lab at METAS (the Swiss Federal Institute of Metrology) and got to observe their atomic clocks, ask the people there some questions, etc.
The scientist in charge of the lab wishes everyone would use TAI for time distribution. TAI has no leap seconds and differs from GPS time by a constant 19 seconds. If TAI was used, computers would never have to worry about leap seconds internally and things would be greatly simplified.
Computers don't care what time i
Re: (Score:3)
I recently took a private tour of the time and frequency lab at METAS (the Swiss Federal Institute of Metrology) and got to observe their atomic clocks, ask the people there some questions, etc.
The scientist in charge of the lab wishes everyone would use TAI for time distribution. TAI has no leap seconds and differs from GPS time by a constant 19 seconds.
Yes, because the Air Force people setting up GPS time didn't understand why that was a fundamental difference between UTC and TAI (GPS - UTC was zero when the time scale was established).
Re: (Score:2)
We're looking at an impact of shifting noon by about a minute over the course of an average human's lifespan.
Maybe not even that since leap seconds can be both inserted and removed as required depending on climatic and geological events. It could very well be a wash.
Re: (Score:2)
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.
GPS does not ignore it in the slightest. GPS is a big user of UT1 data and predicts, and has driven a lot of work in the Earth rotation field. However, what GPS does not do is use UTC as a very approximate version of UT1.
People doing celestial navigation at sea do typically assume that UTC as a very approximate version of UT1, and that's why there are leap seconds at all (to keep the celestial navigation error to the kilometer level). As the use of celestial navigation declines, so does the need for leap s
just a second (Score:5, Funny)
Re: (Score:3)
The cows hate it too.
Re: (Score:3)
It's disturbing that you're modded informative.
Re: (Score:2)
Re: (Score:2)
You need an extra hour of Whoosh! this spring.
Re: (Score:2)
No, I think I'm getting enough just being this close to the informative mods. And utahjazz.
Massive stupidity (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
David Mills approach is a hack around a broken standard, namely POSIX.1. It's a good hack.
Your solution is obvious and correct, but isn't possible to implement while being POSIX compliant.
We all suffer from a broken standard. It's not possible to be both posix compliant and doing this correctly.
Re: (Score:2)
I wouldn't call it unexpected (Score:2)
Anyone who's worked with time zones even a little bit knows that catastrophic failures aren't "unexpected" at all.
Wrong solution, wrong problem (Score:2)
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 w
Re:Wrong solution, wrong problem (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Exactly.
File timestamps should be in linear time (GPS, TAI, whatever).
What gets displayed to you as a human is in your local time - timezone + planetary adjustment - so it matches the time on the wallclock. Do you as a human really care about the LSB in the file time? For those rare times when you do, you'll use linear time.
Blame posix (Score:2)
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 s
beware the Digg effect (Score:3)
counting a second twice (Score:2)
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.
Daily adjustments? (Score:2)
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 problem, and the IMHO correct solution. (Score:5, Interesting)
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/... [wikipedia.org]
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.
Re:The problem, and the IMHO correct solution. (Score:5, Informative)
alternatives (Score:3)
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.
Chicken Little, the sky is not falling (Score:3)
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.
Re: (Score:3)
I would consider t-SQL and *.NET pretty major languages, that completely fail to handle leap seconds.
Re: (Score:3)
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.
Re: (Score:2)
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?
Re:Buggy software is buggy (Score:4, Informative)
Re:Buggy software is buggy (Score:5, Insightful)
The ITU-R has outlined 4 methods for the future of UTC [acma.gov.au]. 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 [xkcd.com].
Re:Buggy software is buggy (Score:5, Funny)
Re:Buggy software is buggy (Score:4, Informative)
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 :)
Re: (Score:2)
Re:Buggy software is buggy (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
Is troll a synonym for insightful now?
Re: (Score:2)
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 m
Re: (Score:2)
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.
Re: (Score:2)
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 see
Re: (Score:2)
Re: (Score:2)
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!
You do know that leap seconds are driven by angular momentum fluctuations in the Earth's liquid outer core? I don't think the Moon has much to do with those.
Re: (Score:3)
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 n
Re: (Score:3)
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.
Re: (Score:2)
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 cod
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
"Aren't all the NTP servers subordinate to the Naval Observatory Clock anyway?"
No.
Re: (Score:2)
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 lo
Re: (Score:2)
I like it too. There's something satisfying about preserving monotonically increasing time.
Re: (Score:2)
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.
Re: (Score:2)
Only photons get to say that; or they would if their birth, existence and obliteration didn't happen in the same instant in their reference frame