Mailing List Archive

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.

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.

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.

On August 3, 2022 11:33:09 AM EDT, 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.
>

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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.
>

On Wed, 3 Aug 2022, Matthew Huff wrote:

> 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.

> -----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.
>
>

---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com https://www.angryox.com/
---------------------------------------------------------------------------

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.

----- 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

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.
>
>

>> > 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-leave-the-leap-second-in-the-past/

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.

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-leave-the-leap-second-in-the-past/
>
> 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.
>
>

Are the people involved in that consensus engineering types?

----- Original Message -----
> From: "Forrest Christian (List Account)" <lists@packetflux.com>
> To: "John Levine" <johnl@iecc.com>
> Cc: "nanog list" <nanog@nanog.org>
> Sent: Thursday, August 4, 2022 4:51:42 PM
> Subject: Re: IERS ponders reverse leapsecond...

> 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-leave-the-leap-second-in-the-past/
>>
>> 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.
>>

--
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

Tom Scott ponders the leap second. And Timezones, and.... and....

https://www.youtube.com/watch?v=-5wpm-gesOY

----- Original Message -----
> From: "jra" <jra@baylink.com>
> To: nanog@nanog.org
> Sent: Wednesday, August 3, 2022 11:09:25 AM
> Subject: IERS ponders reverse leapsecond...

> 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
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
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

On Wed, Aug 3, 2022 at 9:22 AM Jay R. Ashworth <jra@baylink.com> wrote:

>
>
> 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.


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

>

On 8/3/2022 8:09 AM, Jay Ashworth wrote:
> General press loses its *mind*:
>
> https://www.cbsnews.com/news/earth-spinning-faster-than-usual-shortest-day-ever/#app
> <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?

It's somewhere between trivial and straightforward to test
forward/reverse leap seconds with an NTP server and a (dedicated) client.

> Cheers,
> -- jra
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

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

On 8/3/2022 8:33 AM, Matthew Huff 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.
>

--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

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.

On Wed, 10 Aug 2022, Billy Croan wrote:
> 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?

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

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.