General press loses its mind:
https://www.cbsnews.com/news/earth-spinning-faster-than-usual-shortest-day-ever/#app
Have you tested leap second handling, especially in reverse? How do you simulate it? Are there existing test harnesses for simulating it?
Cheers,
– jra
a message of 32 lines which said:
General press loses its *mind*:
Indeed, they seem not to know what they write about. "atomic time –
the universal way time is measured on Earth – may have to change" They
don't even know the difference between TAI and UTC.
True,
But it's hard enough to get developers to understand the need to code for 61 seconds in a minute, and now they would need to code for 59 seconds as well.
If time systems simply skewed the time so that 60 seconds actually just took 61 seconds or 59 seconds, there would be other issues, but coders wouldn't be involved.
Sure.
ALL of this has been gamed out, and I had believed, handled, by the 8601 nerds, and we ignore that investment of work at our peril.
Just to set the standard.
There is no "during" a negative leap second.
A positive leap second proceeds as
23:59:59
23:59:60 <--- second added here
00:00:00
A negative leap second proceeds as
23:59:58
00:00:00 <--- whoops! second 59 is gone!!!
Those systems that "smear" leap seconds over a 24 hour period will
presumably just smear in the reverse direction.
It would not surprise me at all if the liquid outer core keeps on its
slowdown and a negative leap second would need to be scheduled sooner
or later.
Regards
Marshall Eubanks
But it's hard enough to get developers to understand the need to code for
61 seconds in a minute, and now they would need to code for 59 seconds as
well.If time systems simply skewed the time so that 60 seconds actually just
took 61 seconds or 59 seconds, there would be other issues, but coders
wouldn't be involved.
Code will always be prone to failure due to inconsistent and incorrect
assumptions. And blindly trusting dependencies.
Hell, even the smartest engineers at Amazon built AWS using Pacific Time
in the DB rather than GMT/UTC. It was still Pacific Time when I left in
2014.
I'm sure there is/was code to calculate billing related to the jump
forward / fall back between Daylight Saving and Standard Time...
I'm looking forward to January 19, 2038 at 3:14am UTC when the 32-bit Unix
Timestamp will overflow.
This shouldn't cause huge issues, as most systems will not freak out and
die if the system clocks goes from 23:59:58 to 00:00:00. But things that
were supposed to happen at 23:59:59 on that day will never occur.
Hopefully the impact is minimal, but it won't be none.
This is why we've internally standardized on Leap smearing, an added benefit is that it keeps us in sync with Google and AWS who also smear time in the same way.
Daniel Marks
d@nielmarks.com
Occurs to me that "the last second of today" is approximately a million times
more likely as a scheduling target than "the next to last second"; they should
drop 23:59:5*8* instead.
Cheers,
-- jra
Personally I’d like to see the UTC timescale be fixed to the TAI timescale with a fixed offset determined by whatever the offset is when they make the change.
Or stated as a different solution with the same result: quit adding/removing seconds from the TAI to UTC offset.
At the same time, those that rely on UTC being closely related to the historical astronomical meaning of time being related to the rotation of the earth can either move to UT1 (which is in theory more accurate for this purpose), or continue the procedure that is currently used by UTC to create a newly named timescale.
> General press loses its *mind*:
No more than usual. They're just rewriting this Facebook blog post:
It appears that Forrest Christian (List Account) <lists@packetflux.com> said:
Personally I'd like to see the UTC timescale be fixed to the TAI timescale
with a fixed offset determined by whatever the offset is when they make the
change.
That's what Facebook, Google, and AWS want, too. Who knows, for once they might be right.
Having at least a part of one foot in the global time and frequency community I’d say that it seems that the consensus is building toward eliminating leap seconds.
There was a vote planned in 2012 to do so after a straw poll showed that most member countries was in favor to do so. But in a typical committee move they elected to study it more before making a decision.
Hopefully there will be some movement next year when they’re scheduled to discuss it again. It’s unfortunate that the first negative leap second is likely to occur before then.
Are the people involved in that consensus engineering types?
Tom Scott ponders the leap second. And Timezones, and.... and....
Occurs to me that “the last second of today” is approximately a million times
more likely as a scheduling target than “the next to last second”; they should
drop 23:59:58 instead.
You’re probably one of those folks who wonders why all the default Unix daily cron jobs were at 2 AM (which breaks twice a year) and not, say, 4 AM, too.
I certainly am.
Matthew
General press loses its *mind*:
Earth is spinning faster than usual and had its shortest day ever - CBS News
Have you tested leap second handling, especially in reverse? How do you simulate it? Are there existing test harnesses for simulating it?
It's somewhere between trivial and straightforward to test forward/reverse leap seconds with an NTP server and a (dedicated) client.
I've been thinking about this problem for several decades.
I believe I have a Good solution to it. It's the General Timestamp API effort at Network Time Foundation.
If you have been paying any attention, you will immediately realize that the effort is stalled because of a lack of funding.
I'm hesitant to say more, as there are some other groups with partial solutions who think they have the complete solution; and since these groups are much better funded, they are happy to forge ahead based on their view of the world.
I will say that the GTSAPI is designed around a "robust mechanism" that can implement every "local policy choice" I have seen around "how do we want to deal with 'time'?"
It addresses using timestamps beyond the execution of the current boot of the local system, and includes conversions between different versions of different timescales, and a library for arithmetic and comparison functions.
H
Yes.
After all, modern democratic governance can solve any problem…
Next we should vote on those pesky leap years. They’re the work of Julius Cesar, some old white guy who owned a tone of slaves, so anything he came up with is “problematic” and gotta go; and if you disagree someone’s gonna burn down your Walgreens in a peaceful demonstration.
You know, I seem to remember some government body voting a while ago to simplify Pi to exactly 3…
I think a much better answer to the nuisance of leap seconds (their uncertainty), instead of dropping them all together, MIGHT be let them build up for a century and deal with it every hundred years or every thousand. Maybe every decade?
That way when the scheduled time comes, you can be pretty confident an adjustment is needed. Whereas today its anyone’s guess every 3 (6) months.
Then again, as fidgety as humanity is, saying no today might in practice BE the same thing as putting it off until the next century. Then in a few generations they can play catch up if they really need to.
Maybe by 2300, we’ll be able to snapshot Earth (and any other celestial bodies then inhabited by man) and test the change in a ‘sandbox’ before rolling it to prod.
Sheesh. In practice that is what it means to stop doing leap seconds. At some point the drift might be enough that people care enough to do a leap minute or leap hour, but by then it definitely won't be our problem.
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Not that soon! There is not likely to be a leap second for 5 years or so,
based on the current projections.
The value to keep an eye on is UT1-UTC which is required by ITU TF.460 to
be between -0.9s and +0.9s; leap seconds are added by the IERS to keep it
in range. Broadcast time signals include a DUT1 value that is UT1-UTC
rounded to 0.1s precision, which must be between -0.8s and +0.8s.
DUT1 is currently 0.0s.
In the last couple of decades, DUT1 has decreased by about 1ms per day (on
average) which requires a positive leap second every few years.
In 2016, the length of day was 1.5ms greater than 24h; since then the long
term estimated LoD has been fairly steadily decreasing. It dropped below
24h at the end of 2020, and it's now 0.34ms short. (The LoD increased
slowly in the second half of 2021, but it has been decreasing all this
year.)
Depending on the threshold the IERS chooses, the current long-term LoD
estimate suggests a negative leap second some time between the end of 2026
(for a 0.5s threshold) and the end of 2029 (for a 0.9s threshold). That is
without making any more complicated predictions based on the downward
trend of the estimated long-term LoD.
These numbers come from IERS Bulletin A
analyzed by my program
My blog article from when this issue became more well known:
https://dotat.at/@/2020-11-13-leap-second-hiatus.html
My other collected links on this topic
https://dotat.at/writing/time.html