Extra Leap Second To Be Added To Clocks On June 30 289
hcs_$reboot writes: On June 30 this year, the day will last a tad longer — one second longer, to be precise — as a leap second is to be added to clocks worldwide. The time UTC will go from 23:59:59 to 23:59:60 in order to cope with Earth's rotation slowing down a bit. So, what do you intend to do during that extra second added to that day? Well, you may want to fix your systems. The last time a leap second was added, in 2012, a number of websites, Java and even Linux experienced some troubles. Leap seconds can be disruptive to precision systems used for navigation and communication. Is there a better way of dealing with the need for leap seconds?
Leap hour (Score:5, Funny)
There is a better way. Just wait several thousand years and then add one leap hour.
Re: (Score:2)
or several million years, and add a second every day!
Man vs Machine? (Score:5, Interesting)
There are two domains to consider.... human and computer. Humans won't notice or care about sunrise being off by one second or even much more than that. Computers need exact consistency. So the solution is, as stated, to update the clocks to the actual rotation only infrequently. Everyone, man and machine, will be happy.
Re: (Score:3, Informative)
That POS real-time clock mechanism in your average PC holds time as good as a $10 wristwatch
NTP can keep time to within tens to hundreds of milliseconds across the public internet. Plenty good enough for 99.9999% of the applications out there. The RTC only comes into play across reboots. Even Windows has implemented NTP (albeit a crappy implementation that's "only" good to within a second or two) by default for more than a decade now.
Re: (Score:3)
Even Windows has implemented NTP (albeit a crappy implementation that's "only" good to within a second or two) by default for more than a decade now.
The default for Windows 7 (non-domain) is to update once a week, and I routinely found my PVR system off by a minute or more. There is a way to change the update interval [serverfault.com] but you either need to download a special program to make the changes or edit the registry by hand.
Re: (Score:3)
Ignoring the "more stuff would break", this wouldn't help either, as not every day is that 0.000..001% longer. Rotation of the earth is much more irregular than precision timekeeping stuff.
Re: (Score:3)
How accurate is a sextant? If it doesn't accurately provide seconds of arc, a one-second discrepancy won't matter.
Re: (Score:2)
Just wait thousands of years and then not put the clocks forward in march
Re:Leap hour (Score:4, Insightful)
Well, i hope DST would be abandoned sooner.
Re: (Score:2)
An even better way, wait several thousand years and the sun will come up at 7 am instead of 6 am.
Re: Leap hour (Score:3)
There's already "Ephemeris Time" (ET) that doesn't have leap seconds. It's now exactly 26 seconds different from UTC. Go ahead and use that for system time if you like.
Bloody EU, always meddling. (Score:3)
$ cal 9 1752
September 1752
Su Mo Tu We Th Fr Sa
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Better way (Score:5, Interesting)
Re:Better way (Score:5, Informative)
And then over time the astronomical meaning of how we keep time goes astray.
AM and PM mean "anti-meridian" and "post-meridian", and at noon on the day of the summer solstice, the sun should sit on the celestial meridian.
I'm pretty sure if we did it your way, eventually the meridian (which is how we derived both navigation and time keeping) would move around, and eventually noon would be in the middle of the night.
This stuff isn't arbitrary, it's actually based in something.
The whole point of the leap second (etc) is to keep those things lined up. Otherwise there is no way we could keep track of things like sunrise and sunset, or when you might see a specific star.
Re: (Score:2)
Explain the, how DST works in relation to "noon" and "midnight". AM and PM are more like guidelines than actual code.
Re: (Score:3)
Re:Better way (Score:5, Informative)
I think your use of DST was wrong, I think you meant timezones.
Timezones break local noon/midnight by offsetting the location to an approximate less than a half-hour away, but since timezones are calcuated based on the arbitrarily-picked Greenwich, UK, really the entire planet is running on Greenwich time, with a particular significant digit adjusted to reflect distance, to approximate the natural time of the area.
Re:Better way (Score:5, Informative)
arbitrarily-picked Greenwich, UK,
Greenwich wasn't arbitrarily picked. The only options were Paris, Berlin, London and Washington DC -- they had the necessary observatories. London was already in widest common use, and the anti-meridian falls in a convenient place (not crossing anywhere important).
Re: (Score:3)
Re: (Score:2)
Like how people weren't bothered by Y2K bugs? Let's not repeat that every century.
Re: (Score:2)
at noon on the day of the summer solstice, the sun should sit on the celestial meridian.
Many people around the world live in a time zone that's already an hour off. What's a few more seconds/minutes ? All of China has a single time zone, and they still manage to survive.
Otherwise there is no way we could keep track of things like sunrise and sunset, or when you might see a specific star
You don't think we could simply adjust the calculations for sunrise and sunset ?
Re: (Score:3)
I'm glad you phrased it that way. Countless times I have seen people, signs and web sites refer to times such as 12 PM or 12 AM.
There are no such times. It's either 12 noon or 12 midnight.
Re: (Score:3, Informative)
And countless times I see people assume that traditional latin and/or greek roots of terms must be taken literally and dictate how they are to be used in modern times...
Numerous national standards define midnight as 12:00 AM or 0:00 AM, and noon as 12:00 PM. But many also recommend the written usage of "12 noon" and "12 midnight" to make things clear to those that don't understand AM and PM.
Re: (Score:3)
And then over time the astronomical meaning of how we keep time goes astray.
By that logic, the astronomical meaning of how we keep time went astray when we implemented time zones.
Re: (Score:3)
UTC is likewise closely coupled with solar time (UT1) within 0.9 seconds. If you know the offset of a location, you can determine UTC at that location within 0.9 seconds independently, usin
Re: (Score:2)
Re:Better way (Score:5, Informative)
> AM and PM mean "anti-meridian" and "post-meridian",
Total nitpick, its ante not anti.
ante- prefix meaning before
anti - prefix meaning against
You see it in words like "antediluvian" (before the flood).
Re: (Score:3)
UTC [wikipedia.org] doesn't do daylight savings time.
Is there a better way? (Score:2)
No, not really. Leap seconds are a known quantity, make sure your code handles it.
Next question.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
You know in advance already, they are giving you about six months advance notice. Make sure your code handles generic "leap event" with the ability to input the actual values at future, undetermined time ... but in advance of the actual leap event. I could see it requiring at least two inputs, Value change, and time to insert said time.
Should be easy.
Re: (Score:2)
And, before you say you need to know that before you write your code, do you also need to know in advance that "JohnQSmith/aE8&fv84%" might someday be a user's name and password? If you're writing a program which requires deterministic future time intervals, you shouldn't be using the UTC time scale.
Re: (Score:2)
Re:Is there a better way? (Score:5, Insightful)
If you don't need time accurately sync'd to UTC, you can ignore leap seconds, so what's the problem? And if you do need time sync'd to UTC, you will need some regular external input which can include upcoming leap second info, so what's the problem?
TAI if you need it (was Re:Is there a better way?) (Score:3)
If you're doing calculations on time using intervals, and one second matters to you, you should be using a raw number instead of calculating the "23:59:59" yourself. If the UTC conversion is too much, use TAI instead and be done with it:
From http://en.wikipedia.org/wiki/International_Atomic_Time [wikipedia.org]:
Re: (Score:2)
The better way is just to ignore the drift. Define UTC to unrelated to the rotation of the earth or its revolution around the sun. There have been attempts to define UTC this way but is still ongoing. Ie, there's a UT1 time zone that does this and the leap second for UTC is only to keep it within a certain range of UT1.
Leap seconds work just fine (Score:2)
Re: (Score:2)
It is plenty of time. Both human and computer time.
Better way? (Score:5, Insightful)
Sure, use/write software which correctly handles time. Leap seconds with their current, well defined behavior, have been around for over 40 years.
If you have software which assumes a minute is always 60 seconds, an hour is always 60, 60 second minutes, etc., you're doing it wrong.
Re: (Score:2)
Sure, use/write software which correctly handles time. Leap seconds with their current, well defined behavior, have been around for over 40 years.
This is what I was thinking but with OS and hardware. The "slowdown" rate is a known factor. I don't see why modern system that have to be so precise don't already have this factored in. Just have them compensate for the need all the time instead of having to force the issue every few years.
Problem solved.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:Better way? (Score:5, Informative)
Modern UTC ticks at a predictable rate, which is useful for some sciences. Leap seconds keep it in sync with the Earth's rotation, which is useful for others. UTC with leap seconds was deliberately intended to bridge those two needs.
If someone wants a time scale without leap seconds they shouldn't be using UTC, there are others to choose from, such as TAI or GPS.
Re: (Score:2)
The slowdown of Earth's rotation is NOT a known factor, it varies. Things like earthquakes [space.com] can change the period unpredictably.
Yes, I suppose that would make my plan rather difficult to implement.
Re: (Score:2)
Re: (Score:2)
Instead it will crash when one event happens at 23:59:59.8 and another happens at 23:59:60.4 (old notation). In your proposed notation, there would be no way of knowing that event one happened before event two.
In the case of DST, most systems use UTC internally, which doesn't have a notion of DST. Or said in another way, we don't adjust the base clock, we just change time zone.
Re: (Score:2)
So, an event which should run once at 23:59:59 gets run twice? Or if you're logging event sequences, an event which happens later can be logged at an earlier time? I predict big issues with database sync in your future.
When DST happens, there is no duplication of time numbering, the time scale itself changes. 1 AM EDT is not 1 AM EST.
Re: (Score:3)
How about instead of setting the time to 23:59:60, the value 23:59:59 happens twice. When we have DST, and the time falls back an hour, we don't switch to some odd non-existant number for an hour so that we don't have overlap. We just set the clocks back to 1 AM. So all the times between 1 AM and 2 AM happen twice when switching off daylight savings.
The times between 1 AM and 2 AM don't really happen twice on the day daylight time ends, they are simply ambiguous unless daylight or standard time is specified. (In other words, you don't know which of 2 possible seconds 1:42:42 AM refers to until daylight or standard time is specified.) Similarly, your proposal would make 23:59:59 ambiguous without some additional specifier, in which case why not just use 23:59:60?
There is no one perfect solution, which is why there are multiple time standards, including
Re: (Score:3)
Re: (Score:3)
DST isn't so much a problem because if you are doing things right, mostly you store time in UTC and apply the timezone when you display it or convert human inputs from it. Well really some library does this for you using the published tzdata but you get the idea. This gives monotone time, in that its always increasing. Your proposal actually makes things harder because you will end up with two events that logically can't coincide having potentially the same timestamps or even timestamps that appear in th
Re: (Score:2)
Re: (Score:2)
It does, B runs when A says its finished. So now we are looking at the logs, and B has logged a start time before A logged its end time. What does this mean? Does it mean there is a bug in A that caused it to release the lock B was waiting for prematurely? Was everything just fine, but it happen to be clock change night? We can't tell.
23:59:60 being its on distinctly represent second would make what transpired perfectly clear, calling the next second by the same identifier 23:59:59 cases us to lose in
Re: (Score:2)
Oh yes before you say anything. I realize we still have the underlying integer representation. So if we know ahead of time we need to keep that, there is an out.
Now do you want to explain to the PHP how (14205????) 23:59:59 is a time and that 142057???? + 1 is also 23:59:59 but its really a second later. Sounds like a long meeting to me.
Re: (Score:3)
23:59:60 != 00:00:00 is the point.
It's an extra second inserted between 23:59:59 and 00:00:00. During that extra second the clock reads 23:59:60.
Re: (Score:3)
because 23:59:60 isn't 00:00:00. It's 00:00:00-1. Ergo, it should read 23:59:60 otherwise you'll catch the clock in an endless loop as it repeatedly applies the adjustment to 23:59:59 so it reads 23:59:59 again, to have it happen just once you just make the last minute of that one particular day last 61 seconds (remember this is an adjustment to STORED TIME, not DISPLAYED TIME).
Re: (Score:2)
One of the projects I worked on spent weeks just checking that the system could handle leap seconds correctly, which required getting special firmware from the GPS manufacturer which allowed them us trigger artificial leap seconds. The spec for the communication protocol that system implemented had to have special cases purely to handle leap seconds, and someone has to be on call every time it happens just in case something bad goes wrong.
They cause havoc around the world for minimal beneift. Those who care
Re: (Score:2)
If you have software which assumes a minute is always 60 seconds, an hour is always 60, 60 second minutes, etc., you're doing it wrong.
Only once every 40 years or so. Not so wrong in reality, for most applications anyway.
The alternative is pretty a pretty complex bit of programming to "do it right". Those applications that do need to be that accurate, need the complex bits of code, the bulk can just keep using the constants you learned in first grade. All this reminds me of the Y2K hoopla, which was much ado about nothing, or the DST changes of the last few decades which where rife with fear mongering for profit.
I'd say that if your a
Re: (Score:3)
Or just don't worry about it. I work with systems where you must deal with clock drift over time and time drift across the network. So the addition of a second doesn't change much at all. The times when it matters most is with things like satellite navigation systems.
Re: (Score:3)
Life's too short. I'll let NTP deal with it and happily ignore leap seconds.
That's what most people thought before the last leap second, then they found all their Java services sucking up 100% of the CPU in the morning.
Make leap miliseconds (Score:2)
Then engineers build their systems so that they work with leap miliseconds, as otherwise they would fail more often. If your system fails only every 4 years and then only for a few seconds, you won't invest in fixing the problem. If the event occurs more often, then you're forced to.
QA solution to leap second issues (Score:2)
There should be a leap second every month, followed by elimination of a second the following month. That way all code would quickly be adapted to work correctly with leap seconds.
Then of course you have to program to handle the months you don't omit a second because you really wanted the leap second to take...
simple! (Score:2)
>> Is there a better way of dealing with the need for leap seconds?
We just need to make each second last a very little bit longer.
here is the draft set of possible options (Score:5, Informative)
Re: (Score:2, Insightful)
I hope they don't chose option A. It's a hack. We already have a timescale that doesn't add leap seconds: TAI. Changing the definition of UTC is just a hack to fix broken systems. But there are so many other problems with the way systems handle time that it's kind of a moot point.
Properly written software that requires continuance SI-seconds units will use TAI or if they don't need a global reference a local monotonic clock.
Even TAI is something of a lie. Relativity tells us that time is relative, so any gl
Re: (Score:2)
People need to _think_ about the function of time in their applications
Yeah, like that's gonna happen.
and stop pretending like it's a simple problem or that it can solved for you by tweaking international standards.
99% of of software expects a monotomically incrementing time which has 60-minute hours and 60-second minutes. Having the detault time not meet those expectations is moronic, and potentially catastrophic in a world so reliant on computers.
tyson (Score:2)
Solution there, it seems to me, is to inhabit unchangeable-spin planets.
Accuracy of Tools and Software (Score:2)
Investment oportunity (Score:2)
At some point the earth will stop spinning.
The one who will build a forecast model will know which side of the earth will be .... "sunny way up".
Appropriate investment decisions can be made to purchase a land in the twilight zone, where is not too hot and not too cold.
Some sources say, that earth is slowing down 1.7 milliseconds every 100 years. However the last leap second adjustment took place in 2012, http://en.wikipedia.org/wiki/L... [wikipedia.org]
Anybody know a quick and dirty way, a good formula, that would tell us
Re: (Score:2)
"Anybody know a quick and dirty way, a good formula,"
Why sure. We demonstrate the amazing power of DIVISION:
24 hours
-----------------
1.7 ms/100 years
= 5.0823529e+09 years
Re: (Score:2)
Ok, Can you calculate the slow down, if ajdustments were done as follows: one in 2012 next one in 2015, basically every three years.
Re: (Score:2)
According to http://en.wikipedia.org/wiki/T... [wikipedia.org]
> If other effects were ignored, tidal acceleration would continue until the rotational period of Earth matched
> the orbital period of the Moon. At that time, the Moon would always be overhead of a single fixed place on
> Earth. Such a situation already exists in the Pluto–Charon system. However, the slowdown of Earth's
> rotation is not occurring fast enough for the rotation to lengthen to a month before other effects make
> this irrelevant: A
Re: (Score:2)
Thank you for your correction.
Re: (Score:2)
TAI (Score:2)
You could use Atomic time, [wikipedia.org] which is basically UTC but without leap seconds.
This is what's wrong with "renewable" energy (Score:5, Funny)
Easy peasy (lemon-squeezy) (Score:2)
Is there a better way of dealing with the need for leap seconds?
Decrease the radius of the moon's orbit.
time running backwards? (Score:2)
Will my server have "time running backwards" errors tonight? If so, I'll have problems with dovecot mail tomorrow.
Mario Kart (Score:2)
61s in a minute! I will definitely try to beat my best laptime on Mario Kart Wii.
Re: (Score:2)
or maybe I shall pay a visit to the closest nuclear power plant to see it explode. I was so frustrated at Y2K
"Is there... (Score:5, Informative)
...a better way of dealing with the need for leap seconds?"
Well... It could be worse. The last time we let the clocks go off we lost almost two weeks trying to fix it [timeanddate.com].
Let's just keep up with the leap seconds so that nobody has to cancel Christmas again.
Fix NTP (Score:5, Interesting)
The main problem is the wrong handling of UTC by NTP and Unix.
NTP is simply on the wrong time system. It is a system which is designed to accurately keep a monotonous steady time shared among millions of systems spread across time zones. It does not have any sensible way of dealing with the fact that some systems want to suddenly add a second or subtract one, just like it cannot deal with time zones or Mayan calendars. Those are simply outside its problem domain. Luckily the fix is simple: Stop handling leap seconds at all in NTP, just keep counting seconds. If you must handle it in NTP for those client systems too primitive to do it themselves, do it by transmitting the current offset between NTP time and UTC. The best solution would be to define NTP time to be TAI of course, but it will likely have to be TAI+offset to handle backwards compatibility.
Unix again does it wrong by keeping system time in UTC rather than TAI. UTC is useful for humans but difficult for machines, it should be handled by the human interface libraries, just like time zones. Kernel time should be TAI of course. When leap seconds are inserted, systems must be updated, but that is not particularly harder than keeping the time zone files up-to-date is already. Of course it would be a lot easier if the astronomers would let us know a few years in advance rather than six months, but then the offset between TAI and UTC could exceed 0.9 seconds, and as we all know that would bring Ragnarok.
GNU systems even have sets of time zones for precisely this reason: "POSIX" and "Right". Unfortunately it is not possible to use the "Right" time zones with current NTP.
Re: (Score:3)
Unix again does it wrong by keeping system time in UTC rather than TAI.
Actually, that's not what POSIX does, for any definition of "keeping system time in UTC" corresponding to the ITU-R specification [itu.int], as the POSIX definition of "seconds since the Epoch" [opengroup.org] and its mapping to a struct tm doesn't allow the seconds value to be 60, which it will be during a positive leap second.
I.e., it's even more wrong - a POSIX-compliant time_t isn't something that corresponds to TAI (as it doesn't tick forward by 1 every second of elapsed time) and you can't generate valid UTC labels (YYYY-MM-D
Re: (Score:3)
Yes you are right, I had forgotten just how broken POSIX time is. Completely unfixable.
Which is stupid, because struct tm actually supports leap seconds and even (despite them not being possible) double leap seconds.
Thank Doug Gwyn for that one - he pushed that in ANSI C so that it could handle leap seconds.
(And I pushed for leap-second-capable time in POSIX, but they didn't go for it.)
...and whatever data structures are used to keep tract of future scheduled events might have to be updated to reflect that, for example, July 1, 2015, 00:00:00 UTC is going to be one more second later than was expected at the time an event was scheduled for that date and time.
This bit you already have to handle due to daylight savings and time zone changes. If the user inputs a local date and time for a particular event, it is NOT valid to convert and store that as seconds after the epoch. That conversion can change anytime.
Yup, there's no guarantee that, if you calculate the number of seconds between "right now" and YYYY-MM-DD HH:MM:SS, whether that's local time or UTC, that will be the number of seconds in the future when YYYY-MM-DD HH:MM:SS will actually happen.
I wonder how many calendar programs cope with that.
KISS (Score:2)
For the vast majority of cases, leap seconds shouldn't be a problem (or even important). Just note that the clock is wrong and use the built in OS functionality to adjust the clock. (in other words, on a well maintained server, do nothing special)
For things that need a constant time base but not a persistent one, just count the ticks and call it good.
For the really hard cases, we probably need a time base that is simply the number of seconds from a defined base. Then maintain a simple table in the public do
Headline is repetitive and tautological (Score:4, Funny)
Extra Leap Second To Be Added To Clocks On June 30
It's not an extra leap second, it's just a leap second. They're already "extra" by definition.
Yours sincerely,
Captain Pedantic
Re:Earth not _turning_ slower, but already is slow (Score:5, Funny)
The problem is that you don't understand it.
Re: (Score:2)
Every large earthquake changes the rotation speed. The big 8.x one a few years ago, the one with the Tsunami, that one significantly changed rotation.
Re:Earth not _turning_ slower, but already is slow (Score:5, Informative)
No, the Earth really is slowing down very, very gradually. The tidal forces from the moon is slowly leeching off rotational energy from the Earch (as heat). See here: http://en.wikipedia.org/wiki/T... [wikipedia.org]
Re: (Score:3)
Note to self: get more sleep before commenting....it's losing rotational energy to pushing the moon farther away. Gah.
Re: (Score:3)
Re: (Score:3)
This post right here is why we need a "Post Inaccurate" option for modding.
Re:Do the impossible (Score:5, Funny)
All we need to do is have everyone in the world face west and run.
Re: (Score:2)
Hit it? why? The earth is already being slowed down by tidal interactions with the moon. we just need to slow the moon down until it drops under geosynchronous orbit, then its tidal bulge will move faster than our rotation and rotational energy will transfer from the moons new orbit to earth's rotation.
There are a couple of minor downsides....like massive increases in the amplitude of the tidal bulge, but moon missions will require a lot less delta v...... of course, it also means the moons orbit will progr
Re: (Score:2)
XKCD has it covered: https://what-if.xkcd.com/26/ [xkcd.com]
Re: (Score:3)
23:59:59 is normally followed by 00:00:00 (or 24:00:00). In this case it goes 23:59:59, 23:59:60, and then 00:00:00. One second gets added at the end of the day.
Re: (Score:2)
Making the generous assumption that this is a brain slip and not a troll, seconds don't normally go up to 60. They stay in the range of 0..59, which means there's sixty of them. Counting from 0 to 60, including the 0, gives you 61 seconds in that minute.