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. -----Original Message----- From: NANOG <nanog-bounces+mhuff=ox.com@nanog.org> On Behalf Of Stephane Bortzmeyer Sent: Wednesday, August 3, 2022 11:19 AM To: Jay Ashworth <jra@baylink.com> Cc: nanog@nanog.org Subject: Re: IERS ponders reverse leapsecond... On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth <jra@baylink.com> wrote 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.

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 On Wed, Aug 3, 2022 at 11:35 AM Matthew Huff <mhuff@ox.com> wrote:

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.

-----Original Message----- From: NANOG <nanog-bounces+mhuff=ox.com@nanog.org> On Behalf Of Stephane Bortzmeyer Sent: Wednesday, August 3, 2022 11:19 AM To: Jay Ashworth <jra@baylink.com> Cc: nanog@nanog.org Subject: Re: IERS ponders reverse leapsecond...

On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth <jra@baylink.com> wrote 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.

----- Original Message -----

From: "Peter Beckman" <beckman@angryox.com>

On Wed, 3 Aug 2022, Matthew Huff wrote: 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.

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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

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 ------- Original Message ------- On Wednesday, August 3rd, 2022 at 11:33 AM, Matthew Huff <mhuff@ox.com> wrote:

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.

-----Original Message----- From: NANOG nanog-bounces+mhuff=ox.com@nanog.org On Behalf Of Stephane Bortzmeyer

Sent: Wednesday, August 3, 2022 11:19 AM To: Jay Ashworth jra@baylink.com

Cc: nanog@nanog.org Subject: Re: IERS ponders reverse leapsecond...

On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth jra@baylink.com wrote 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.

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. On Wed, Aug 3, 2022, 8:20 AM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:

On Wed, Aug 03, 2022 at 11:09:25AM -0400, Jay Ashworth <jra@baylink.com> wrote 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.

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. On Thu, Aug 4, 2022, 11:32 AM John Levine <johnl@iecc.com> wrote:

...

...

...

General press loses its *mind*:

No more than usual. They're just rewriting this Facebook blog post:

https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-lea...

...

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

It appears that Forrest Christian (List Account) <lists@packetflux.com> said: the

...

change.

That's what Facebook, Google, and AWS want, too. Who knows, for once they might be right.

On Thu, Aug 4, 2022, 15:53 Forrest Christian (List Account) < lists@packetflux.com> wrote:

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.

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.

Forrest Christian (List Account) <lists@packetflux.com> wrote:

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.

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 https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html analyzed by my program https://github.com/fanf2/bulletin-a/ 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 -- Tony Finch <dot@dotat.at> https://dotat.at/ Thames, Dover, Wight, Portland, Plymouth: Northeast 3 to 5, veering east 2 to 4 later in Thames, Dover and Wight. Smooth or slight, but in Plymouth slight, occasionally moderate at first in west and smooth later in northeast. Fair. Good.