Earth Is Whipping Around Quicker Than It Has In a Half-Century (livescience.com) 105
The 28 fastest days on record (since 1960) all occurred in 2020, with Earth completing its revolutions around its axis milliseconds quicker than average. Live Science reports: That's not particularly alarming -- the planet's rotation varies slightly all the time, driven by variations in atmospheric pressure, winds, ocean currents and the movement of the core. But it is inconvenient for international timekeepers, who use ultra-accurate atomic clocks to meter out the Coordinated Universal Time (UTC) by which everyone sets their clocks. When astronomical time, set by the time it takes the Earth to make one full rotation, deviates from UTC by more than 0.4 seconds, UTC gets an adjustment.
Until now, these adjustments have consisted of adding a "leap second" to the year at the end of June or December, bringing astronomical time and atomic time back in line. These leap seconds were tacked on because the overall trend of Earth's rotation has been slowing since accurate satellite measurement began in the late 1960s and early 1970s. Since 1972, scientists have added leap seconds about every year-and-a-half, on average, according to the National Institute of Standards and Technology (NIST). The last addition came in 2016, when on New Year's Eve at 23 hours, 59 minutes and 59 seconds, an extra "leap second" was added.
However, according to Time and Date, the recent acceleration in Earth's spin has scientists talking for the first time about a negative leap second. Instead of adding a second, they might need to subtract one. That's because the average length of a day is 86,400 seconds, but an astronomical day in 2021 will clock in 0.05 milliseconds shorter, on average. Over the course of the year, that will add up to a 19 millisecond lag in atomic time.
Until now, these adjustments have consisted of adding a "leap second" to the year at the end of June or December, bringing astronomical time and atomic time back in line. These leap seconds were tacked on because the overall trend of Earth's rotation has been slowing since accurate satellite measurement began in the late 1960s and early 1970s. Since 1972, scientists have added leap seconds about every year-and-a-half, on average, according to the National Institute of Standards and Technology (NIST). The last addition came in 2016, when on New Year's Eve at 23 hours, 59 minutes and 59 seconds, an extra "leap second" was added.
However, according to Time and Date, the recent acceleration in Earth's spin has scientists talking for the first time about a negative leap second. Instead of adding a second, they might need to subtract one. That's because the average length of a day is 86,400 seconds, but an astronomical day in 2021 will clock in 0.05 milliseconds shorter, on average. Over the course of the year, that will add up to a 19 millisecond lag in atomic time.
Obvious answer (Score:5, Funny)
Even Earth wanted to get 2020 the fuck over with.
Re: (Score:1)
Re: (Score:3)
Well, it will need to do it again for this year. :(
Re: (Score:1)
Either that or it's just jumping for joy.
Maybe... (Score:3)
The Earth orbit is decaying and we are going spiral into the Sun. Thank you 2020!
Re: (Score:2)
Re: Maybe... (Score:1)
You say that now, but just wait until we fly into the sun!
Extraordinarily unlikely (Score:3)
Re: (Score:2)
Re: (Score:2)
https://slashdot.org/~msauve observed:
Excellent example of a run-on sentence, KODOS!
FTFY ...
Re: (Score:1)
Re: (Score:2)
Can we just ditch leap seconds? Who really needs them, and is their need great enough to justify all the hassle they cause?
The issue with leap seconds is that they are not predictable, so every device that uses them has to be updated to know there is one coming. It also screws up some systems that can't cope with there being 61 seconds in a minute.
Let's say we just abandon them and UTC gets 30 seconds or a minute out from the position of the Earth in it's orbit around the sun, what would the consequences be
Re: Extraordinarily unlikely (Score:2)
If you don't want leap seconds, just use TAI instead of UTC.
The difference is currently 37 seconds.
Re: (Score:2)
The issue with leap seconds is that they are not predictable, so every device that uses them has to be updated to know there is one coming.
Every device needs to be able to be updated anyway. If your device can't be updated, you bought the wrong device. If your device doesn't get updated, you bought the wrong device.
It also screws up some systems that can't cope with there being 61 seconds in a minute.
See above, but change "needs to be updated" to "needs to work in the real world".
Re: (Score:2)
Lets just say you abandon them and are 30 seconds out of sync with those people who follow UTC, what would the consequences be? We have another time system, in fact several. Use whichever one you want on your non-connected device.
Unless you have an atomic clock at home at some point you're going to drift with the actual time anyway. If you have a device which syncs time then the leap second isn't an issue for you.
Re: (Score:2)
The main issue is that a lot of stuff specifies UTC for timestamps, so you can't just use other system without risking breakage.
Re: (Score:2)
Again if you have a system which relies on accurate timestamping than the *only* solution is some kind of a syncing, and then you either sync between the systems to eliminate the problem, or you sync to a reference time online at which case you effortlessly correct for leap seconds.
The world is absolutely crammed full of time critical applications that absolutely depend on millisecond accurate timing from the sharing of time series data, the analysis of timestamped logs, or even more critical things such as
Re: (Score:1)
Re: (Score:2)
The following is from the IETF's Leap Second List [ietf.org] file...
# 4. The decision to insert a leap second into UTC is currently
# the responsibility of the International Earth Rotation and
# Reference Systems Service. (The name was changed from the
# International Earth Rotation Service, but the acronym IERS
# is still used.)
#
# Leap seconds are announced by the IERS in its Bulletin C.
#
# See www.iers.org for more details.
#
# Every national laboratory and timing cent
Re: (Score:2)
In 1969 the members of the CCIR working groups did not believe that they could wait for such an international agreement. The only proposal for which they could get international agreement had leap seconds. they gave that proposal to the bureaucrats who approved it even though they had had reports describing how leap seconds would cause trouble. Achieving internationa
One more line of context would have made sense (Score:3, Interesting)
"It's quite possible that a negative leap second will be needed if the Earth's rotation rate increases further, but it's too early to say if this is likely to happen," physicist Peter Whibberley of the National Physics Laboratory in the U.K., told The Telegraph.
Let time be its own thing (Score:1)
Re:Let time be its own thing (Score:5, Informative)
It pretty much is. But there are applications where you want time that is closely synchronized with Earth's rotation. That's where leap seconds come in.
...laura
Re: (Score:2)
Re: (Score:3)
The first half was that Germany made it illegal to broadcast mean solar seconds
I'm German, I'm a nerd, I know that we have a (real short) Federal Time Law, so just out od curiosity, could you give me a pointer to that?
Re: (Score:3)
Wouldn't you rather have a reference?
Since you are using pointers then you must be using C or C++.
I guess an actual value, i.e. the text of the law, would work too.
And the good part about that is that you can highlight parts of it and it won't change what the German Bundestag, is that right, has written.
Re: (Score:2)
Touché.
Re: (Score:2)
Re: (Score:2)
Thanks. So it was rather the introduction of the more constant atomic second compared to the solar second.
Re: (Score:2)
Re: (Score:2)
It pretty much is. But there are applications where you want time that is closely synchronized with Earth's rotation. That's where leap seconds come in.
Please name one. One that uses UTC today and actually requires within-one-second relation with the Earth rotation. The vast majority of timekeeping has no problem with being an hour or more off from the Earth rotation. We know that because it happens every summer in many locations.
Re: (Score:2)
Astronomy.
You're right that for civil purposes seconds rarely matter. But you still want to avoid buildup. The few hours of the old leap year rule never mattered to anyone, too - but over the centuries it added up to 14 days. And that mattered ad required a disruption in the continuous day counting that until today, requires dates to be converted to julian date to to math with them.
Re: (Score:2)
Astronomy does not run on UTC. 1 second off is not good enough for astronomy. Astronomers are REALLY good at time-keeping.
Have you calculated the actual build-up? Time zones change every decade or so on average. The build-up for 15 minutes takes a thousand years. We can chuck the 15 minutes into one of the dozens of time zone changes that will happen anyway in the next thousand years.
Re: (Score:2)
Timezone changes don't effect UTC, just UTC offset.
Re: (Score:2)
Timezone changes don't effect UTC, just UTC offset.
Exactly the point. There is no need to mess with UTC. Only a tiny minority of the world lives on UTC itself, and most of them only part of the year. For the rest of the world, it makes no difference where the sun is at 12 noon UTC. It matters where the sun is at 12 noon local time (within an hour or 3 at least, but some have worse offsets).
It is literally the job of the time zones to keep local time aligned with the sun. Yet for some reason we have decided to mess up the length of the minute instead of usin
Re: (Score:2)
[quote]Umm what? UTC is the same everywhere.[/quote]
When there is a leap second servers are mainly in 3 categories.
a) "correct". Following UTC. Practically zero servers are in this category. There are hardly any time sync servers you can sync against for this.
b) "broken". Making 1 second 2 seconds long. All servers who follow standard NTP are supposed to do this,
c) "workaround". Spreading the extra second out over an hour. Google runs that way, and there are NTP servers you can use that deliver smeared time
Re: (Score:2)
Going back to the inception, astronomers did not want leap seconds. Astronomers submitted the only known report which described how disruptive leap seconds would be. One by one, every warning and suggestion from astronomers was ignored during the negotiations that led to leap seconds.
Re: (Score:2)
Astronomers are the ones who keep voting down proposals to drop leap seconds. They are not the reasonable side, they are strange fanatics who do not even use the time they force on the rest of us.
And yes, the quadratic problem makes it even worse. We will hit having leap seconds every month, then every day. Leap seconds do not solve anything, and certainly not the problem they pretend to solve.
Re: (Score:3)
Re:Let time be its own thing (Score:4, Informative)
What you are suggesting exists and is called TAI. https://en.wikipedia.org/wiki/... [wikipedia.org]
You are free to use it if it fits your needs better than the usual light-during-day, dark-at-night concept, that ensures constant length of each day, removing the effects of that "imperfect movement"
P.S. If you don't like it, you are not forced to use DST either. Set up a clock as "Farm Time" and milk your cows every morning at 7am Farm Time if that's easier for you than transitioning from 7am regular time to 7am DST.
The flow of time is an unstoppable force of nature. But the measuring of time is completly arbitrary and man-made. Each group of stake holders can find their own way to measure or name it. Remember the Swatch Beats? UTC, UTC+-. your timezone, UT0, TAI, Astronomical time... Mix'n'Match! You're welcome.
Re: (Score:2)
Except for particles that travel at the speed of light or, perhaps also, inside a black hole. As Einstein showed, time is relative to the observer. There is no universal rate at which time progresses.
Re: (Score:2)
P.S. If you don't like it, you are not forced to use DST either. Set up a clock as "Farm Time" and milk your cows every morning at 7am Farm Time if that's easier for you than transitioning from 7am regular time to 7am DST.
"Farm Time" is when the sun comes up and goes down. It does not care about things like "7 AM", etc.
Re: (Score:1)
The flow of time is an unstoppable force of nature.
Time is an averaged measure of entropy defined by man and not something which exists inherently in physics. There's no such thing like time in an entropy-free system.
Re: Let time be its own thing (Score:1)
Negative leap second (Score:3)
Variations (Score:3)
Re:Variations (Score:4, Insightful)
One I can think of girth by mass. Suck out a load of underground water from the sunny dry regions of the land and dump it in the oceans and you get less mass in the equatorial band. This equates to a tighter girth which in turn, speeds up rotation.
Re: (Score:3, Interesting)
Re: (Score:3)
Yep, that's the reason for the overall dramatic slowing of rotation, but this is speeding up the Earth's rotation. Albeit on a much much shorter timescale.
My theory: (Score:3)
Excellent (Score:3)
Crap! I'm going to be late... (Score:2)
Do you think that the PHB will accept the excuse?
Unix time + leap seconds = heartache (Score:4, Interesting)
Wiki: "[Unix time] is the number of seconds that have elapsed since the Unix epoch, [without] leap seconds; the Unix epoch is 00:00:00 UTC on 1 January 1970 (an arbitrary date); leap seconds are ignored,[4] with a leap second having the same Unix time as the second before it, and every day is treated as if it contains exactly 86400 seconds."
Rather than keeping the definition of Unix time dirt simple such as "the number of seconds that have elapsed since the Unix epoch" they decided to complicate and confuse it by effectively incorporating unpredictable astronomical calendar adjustments into their basic definition and representation of time keeping. Sweet!
This means that if you try to calculate the total amount of time that has passed between two Unix timestamps that it can't be done accurately without reference to the astronomical calendar adjustments. Awesome! Who wants to do simple linear arithmetic anyway? Lookup tables and discontinuities are so much more fun instead!
Since an added leap second jumps Unix time backwards by one second when it occurs, programs that try to use Unix time for time tracking will get into weird time jumps and/or pauses. A subtracted leap second will jump the Unix clock forwards by one second and you'll get similarly weird time effects.
One way to get around this is to instead use different special clocks that don't have these leap second jumps. Local monotonic clocks don't jump but their offsets are usually not synchronized to any other source, so they must be adjusted to compare times across clocks and even runs. (This is the right way to track the passage of time within a program anyway.) Another method used by Google and others is to instead smear this problem away by slowing down (or speeding up) the apparent passage of Unix time by a leap second over 20 hours -- intentionally introducing error in time keeping, stamping, and arithmetic (and creating yet another definition of time) but at least avoiding the idiocy of unnecessary clock jumps while mostly staying in-sync with Unix time.
This also means that Unix timestamps are no longer unique and unambiguous. Oh, your timestamp happened to fall in the wrong second? Well, was it the first second or the repeated second? Who knows? It could be either! It also means there are timestamps that are never used at all when time jumps forward due to a negative leap second. Yay for discontinuities and ambiguities in the timeline!
Whoever came up with this definition of Unix time did the world a great disservice. TAI would have been a better choice and left the complexity of converting a timestamp to a calendar date where it belongs. Trying to set a timer to go off at a specific UTC time in the future (which is unpredictable due to Earth's wibbily wobblyness) should be the hard case rather than complicating all time keeping, tracking, calculations, etc. in general to try to make that easier.
Re: Unix time + leap seconds = heartache (Score:3)
Re:Unix time - leap seconds = happy days. (Score:4, Informative)
As it is, you don't need any knowledge of leap seconds to convert a UNIX timestamp into a date and time. A program written and compiled in 1970 could still accurately convert this moment's UNIX timestamp into this moment's time. That is simplicity. Simplicity where it matters.
While 'number of seconds since 1970' sounds simple, implementing it is complex.
This means that accurately calculating the number of seconds between two UNIX timestamps will require knowledge of leap seconds. Needing to be worried about the second's inaccuracy in a timestamp difference is something that almost never matters.
So the people who made the decision for UNIX time to ignore leap seconds unquestionably made the right decision.
Re: (Score:3)
A program written and compiled in 1970 could still accurately convert this moment's UNIX timestamp into this moment's time.
Only in select few locations. Most locations have had timezone changes since 1970.
Re: (Score:2)
And those timezone changes had absolutely zero effect on unix timestamps ...
Re: (Score:2)
But they had a lot of effect on "this moment's time".
Re: (Score:3)
> A program written and compiled in 1970 could still accurately convert this moment's UNIX timestamp into this moment's time.
That's what UTC is for without all the heartache that Unix time incurs.
What you are really saying is that we should complicate all time keeping, tracking, computation, etc., forever just so that we can more easily convert a date into a number and vice versa. A number with a lot of drawbacks and pitfalls as I laid out. Just because dealing with a UTC timestamp's components is ever s
Re: (Score:3)
Also important to remem
Re: (Score:3)
> I happen to think - and the experienced programmers who made this decision agree with me - that converting between UTC and the internal timestamp is very important, as is converting between it and the local timezone.
I agree. There should be standard library functions that does these conversions, timers, and calendars very well for everyone. Why should there instead be a false rule of thumb like "every day is 86400 seconds, regardless of reality" instead? So that every program can maybe try to do such c
Re: (Score:2)
I agree. There should be standard library functions that does these conversions, timers, and calendars very well for everyone. Why should there instead be a false rule of thumb like "every day is 86400 seconds, regardless of reality" instead? So that every program can maybe try to do such calendar calculations themselves inline? What kind of BS argument is that?
I have written such a library. The essence of it is that applications should not use the POSIX time_t data type for telling time, but instead use the POSIX tm data type. For documentation and source code see this URL: https://commons.wikimedia.org/... [wikimedia.org] .
The source tarball is on github at ShowControl / libtime, and it can be installed from Fedora COPR at johnsauter / libtime.
Re: Unix time - leap seconds = happy days. (Score:2)
Doing interval calculations is 99% of the use case for timestamps.
And yes, to most people, millisecond precision is required, if not nanosecond or picosecond precision for specialized applications.
What kind of deranged world do you live in where things being off by a whole second is ok?
Re: (Score:2)
every program needing to
Wow, hold up there mate. That sounds like something that can be handled easily by an API.
Re: (Score:3)
> While 'number of seconds since 1970' sounds simple, implementing it is complex.
No, it is actually the simplest possible thing you could do. We've been running atomic clocks since the 1950s. All you need to do is literally ask the atomic clock (service) how many SI seconds have passed since the reference time. That's it. That's your timestamp. Done and done.
> This means that accurately calculating the number of seconds between two UNIX timestamps will require knowledge of leap seconds.
That's what you
Re: (Score:2)
Re: (Score:3)
> Do you really want every time a program needs to calculate the time - or any time - to require leap second calculations?
Do you mean convert a system clock time to a datetime and vice versa?
If that's what you mean, then there should be very good standard library functions (e.g. - ctime, gmtime, localtime, asctime, mktime) that do that for you very well and that do account for known leap seconds.
Very few programs should be doing time calendar calculations themselves directly inline. And we certainly sho
Re: (Score:2)
Re: (Score:2)
Do you really want every time a program needs to calculate the time - or any time - to require leap second calculations?
As it is a program needs to do a lookup to timezones be able to tell you the time. Whether that look up additionally checks how many leap seconds have passed is completely irrelevant. What Unix fucked up is the ability to calculate time elapsed between two events which is a far more important programming concept than displaying a number to a user, and surprise, one for which you are now required to do leap second calculations.
There is nothing to be gained or lost here. One way or the other you need to do a
Re: (Score:2)
Sorry, as long as users want to mark UTC time in computer by a single number, be it in unit of second / millisecond / nanosecond, it has to ignore leap seconds in the counting, and use slow down or speed up to handle the leap when one want to make it truly precise.
What will happen when one use TAI to record timestamps instead? One will become IMPOSSIBLE to convert a future UTC time into that number. As leap seconds are decided by human, not predictable formula, TAI and UTC is not always convertible. So,
Re: (Score:2)
> Sorry, as long as users want to [represent] UTC time in computer by a single number ...
That's impossible to do well for future times because UTC sprinkles in and removes random-ish extra seconds here and there as time passes. If you want to represent a UTC time well, then you need to do it in UTC, which has multiple time subcomponents and accounts for leap seconds. You can't boil all future UTC times down to a single number well a priori due to UTC's fundamental definition.
If you try regardless, then y
Re: (Score:2)
Unix time tries to achieve what you want by screwing with our base conception of what a second is and destroying timestamp arithmetic all because it wants to represent something in a single number that can't be done well. That's a terrible decision.
If timestamp arithmetic is destroyed this easily, then it has been destroyed already. Computer clocks drift over time. They can't maintain sub-second accuracy without constant contact over Internet to those expensive atomic clocks. In practice, leap seconds can be handled just like those usual NTP clock calibration, assuming "Oops our clock in this computer/smartphone is found to be one second faster than the correct time!" Dial it back, and be done with it.
Wikipedia said even for thermocompensated quart
Re: (Score:2)
> If timestamp arithmetic is destroyed this easily, then it has been destroyed already.
Yes, although not for the reasons you state. If you try to do Unix timestamp arithmetic between now and, say, 20 years from now, then your interval will be wrong by however many leap seconds are added (and/or removed) between now and then. We've been averaging a leap second every ~1.5 years. If that keeps up, then you'd be off by ~13 seconds of real SI time.
> Computer clocks drift over time. They can't maintain sub-
What if it halts? (Score:2)
Maybe at some point it'll suddenly halt its spin shed all the crap that's on it, like a dog drying itself.
We should fix that (Score:1)
Those leap seconds are a pain for software. We should fix the rotation. How hard could that be?
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
do we want to run out of time or live in an end of (Score:1)
RINO astronomers (Score:4, Funny)
Re: (Score:2)
Even the universe was sick of his shit and wanted it to end faster.
That's to be expected (Score:2)
We are all huddled inside instead of breaking the earth's speed by standing outside in the wind.
That explains... (Score:2)
...why I haven't been getting as much done; the days are shorter. Can't wait until Elon and I move to Mars, where the length of the day is just under 24h 40m--think how much I'll get done then!
Crap! I'm gonna be late! (Score:1)
Why not something... (Score:1)
The earth's rotation is always changing. 10 million years ago it was much different.
How about using the period of a hydrogen atom's electron. And start counting from the big bang.
Call it Cosmic Count Time (CCT). This way, time can be the same everywhere, and real truth can remain apparent.
This way, we can all be aware of the changes in things like earth's rotation, or length of orbit around the Sun (a year).
We're in the future! (Score:1)
Re: (Score:3, Funny)
We're just trying to come up with an androgenic angle so we can shut down some factories or mines or something.
Re: (Score:2)
Global warming should have the opposite effect.
As glaciers melt in Greenland, Siberia, Antarctica, etc., and the meltwater flows into the oceans, the mass is moved from the polar regions and distributed evenly over the world.
The melting should increase the earth's moment-of-inertia. Since angular-momentum is conserved, the higher MOI should slow the earth.
A warming atmosphere should also slow the earth.
So why is it speeding up? TFA doesn't say.
Re: (Score:2)
I imagine it's because the ice locked up in the mountains was further from the center of the earth, so by melting and not being as much on the mountains, it's like pulling in the arms of a figure skater, speeds up.
Re: (Score:2)
Further from the center is not what matters. What matters is further from the axis of rotation.
Most melting glaciers are in polar regions, not in equatorial mountains.
Re: The increasingly nightmarish online experience (Score:1)
That's a pretty elaborate pasta.
What's the story behind it?