Subject: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 04:14:35 -0700

[email-masked] said:
> I can 100% attest to this. All of my colleagues and superiors that I've ever
> talked to about this were shocked and appalled to learn that the WG was
> considering anything other than UTC as the basis for dissemination.

Note that GPS and similar are not using UTC as the "basis for dissemination".  They use something without leap seconds.  They also provide enough information for a client to translate their time to UTC.

> In that vein, I'm also supposed to communicate that the whole issue might
> become moot "soon", since leap seconds might just be removed as a thing
> that happens in UTC. 

I haven't been following that and I haven't noticed anything recently.  Can anybody provide any info on what is going on?  What are the chances they will go away?  If so, when?

-- 
These are my opinions.  I hate spam.

---

From: [email-masked]
Date: Thu, 21 Oct 2021 13:59:18 +0200

"ntp" <[email-masked]> schrieb am 21.10.2021 13:14:35:
> > I can 100% attest to this. All of my colleagues and superiors thatI've 
ever
> Note that GPS and similar are not using UTC as the "basis for 
> dissemination".  They use something without leap seconds.  They also
> provide enough information for a client to translate their time to UTC.

Right; neither does PTP. 
And that all makes absolute sense, as far as I'm concerned. 
Fact remains that it is a point of concern for people in that field in 
NMIs, many of whom have spent years trying to get as many things as 
possible to use UTC.
I'm saying that we should be aware of that in this whole debate.

> I haven't been following that and I haven't noticed anything 
> recently.  Can anybody provide any info on what is going on?  What 
> are the chances they will go away?  If so, when?

I only have second-hand insight, really.
What I gather is that there is a growing fear of a situation similar to 
the Y2K bug scare, because it is predicted that (for the first time I 
believe) there could soon be a negative leap second and time sync 
appliances might just fail in the face of having to deal with that.
I will try to get better info, in particular quantifying chances and 
timeframe.
 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Doug Arnold <[email-masked]>
Date: Thu, 21 Oct 2021 13:32:17 +0000

We've done negative leap second tests at PTP plugfests, and many implementations had problems.

________________________________
From: ntp <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, October 21, 2021 7:59 AM
To: Hal Murray <[email-masked]>
Cc: [email-masked] <[email-masked]>; ntp <[email-masked]>
Subject: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

"ntp" <[email-masked]> schrieb am 21.10.2021 13:14:35:
> > I can 100% attest to this. All of my colleagues and superiors thatI've ever

Right; neither does PTP.
And that all makes absolute sense, as far as I'm concerned.
Fact remains that it is a point of concern for people in that field in NMIs, many of whom have spent years trying to get as many things as possible to use UTC.
I'm saying that we should be aware of that in this whole debate.

I only have second-hand insight, really.
What I gather is that there is a growing fear of a situation similar to the Y2K bug scare, because it is predicted that (for the first time I believe) there could soon be a negative leap second and time sync appliances might just fail in the face of having to deal with that.
I will try to get better info, in particular quantifying chances and timeframe.

---

From: [email-masked]
Date: Thu, 21 Oct 2021 15:37:45 +0200

Just to update on the possibility of leap seconds being removed from UTC 
as a feature:
- I have gotten a document that I can look into, but have to clear up how 
much and what I am at liberty to make public here.
- I can say that the timeframe is so that nothing of consequence is likely 
to change this decade; so (depending on how slowly we intend to work), we 
should probably treat this change as irrelevant for the design of NTPv5
- The proposal might not even be that leap seconds go away, it might just 
be that more than the current one second is allowed as a maximum 
difference between solar time and UTC (meaning leap seconds would happen 
even less frequently).

The whole issue is a bit politically/socially (?) charged, where some 
people have a fundamental resistance of de-coupling coordinated time from 
experienced (solar) time.
A bit strange for me personally, seeing as timezones have a resolution of 
1h typically, so it is obviously perfectly fine to live with a difference 
of up to 30 minutes between an individual location's solar time and UTC (I 
kinda hope the solution is to increase the maximum difference to an hour, 
so that the rest can be "sensibly" regulated via time zones instead of 
leap somethings).

Anyway, it is what it is.
Best regards to all

Von:    [email-masked]
An:     "Hal Murray" <[email-masked]>
Kopie:  [email-masked], "ntp" <[email-masked]>
Datum:  21.10.2021 14:00
Betreff:        Re: [Ntp] New Version Notification for 
draft-gruessing-ntp-ntpv5-requirements-03.txt
Gesendet von:   "ntp" <[email-masked]>

ever

Right; neither does PTP.

---

From: Danny Mayer <[email-masked]>
Date: Thu, 21 Oct 2021 11:29:18 -0400

On 10/21/21 7:59 AM, [email-masked] wrote:
> What I gather is that there is a growing fear of a situation similar 
> to the Y2K bug scare, because it is predicted that (for the first time 
> I believe) there could soon be a negative leap second and time sync 

The only way that is likely to happen is if the earth rotation speeds 
up, which is extremely unlikely. The only ways that I can think of that 
happening would be either a volcano about to spew enough energy in the 
right direction and an asteroid hitting the earth with a glancing blow. 
Either would be catastrophic. It would be better to not remove a 
leapsecond and just wait for the next time a positive leapsecond 
adjustment is needed.

Danny

---

From: James <[email-masked]>
Date: Thu, 21 Oct 2021 17:52:47 +0200

As was reported earlier this year [1]:

> Peter Whibberley, senior research scientist with National Physical Laboratory’s time and frequency group, said: “It is certainly correct that the Earth is spinning faster now than at any time in the last 50 years.
> ...
> The World Radiocommunication Conference will decide on the fate of the leap second in 2023.
> ...
> Global warming will also have an effect by melting ice and snow at higher elevations, causing the Earth to spin faster, although only by a small amount.

I’d be curious to know if there are any data that contradicts the NPL’s position regarding rotation speed or the other parts of that article.

- J

1: https://www.telegraph.co.uk/news/2021/01/04/earth-spinning-faster-now-time-past-half-century/

> On 21 Oct 2021, at 17:29, Danny Mayer <[email-masked]> wrote:
> On 10/21/21 7:59 AM, [email-masked] <mailto:[email-masked]> wrote:
> The only way that is likely to happen is if the earth rotation speeds up, which is extremely unlikely. The only ways that I can think of that happening would be either a volcano about to spew enough energy in the right direction and an asteroid hitting the earth with a glancing blow. Either would be catastrophic. It would be better to not remove a leapsecond and just wait for the next time a positive leapsecond adjustment is needed.
> 
> Danny
> 
>

---

From: [email-masked]
Date: Thu, 21 Oct 2021 20:51:41 +0200

Yeah, sorry, I forgot to add that these weren't idle fears.
The earth rotation does appear to be speeding up right now, it is just a bit unclear whether or not it will *keep* doing it long enough for that negative leap second to become necessary.

If it does, it seems to also be uncertain whether the planned change will come in time to prevent it from being a thing operators have to deal with (since, as I said, the change likely won't be this decade).

Kristof

-----"James" <[email-masked]> schrieb: -----

An: "Danny Mayer" <[email-masked]>
Von: "James" <[email-masked]>
Datum: 21.10.2021 17:52
Kopie: [email-masked], "Hal Murray" <[email-masked]>, "NTP WG" <[email-masked]>
Betreff: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

- J

On 10/21/21 7:59 AM,
 [email-masked] wrote:

I only have second-hand insight,
 really.
What I gather is that there is a
 growing fear of a situation similar to the Y2K bug scare,
 because it is
 predicted that (for the first time I believe) there could soon
 be a negative
 leap second and time sync appliances might just fail in the
 face of having
 to deal with that.
I will try to get better info,
 in
 particular quantifying chances and timeframe.

The only way that is likely to happen is if the earth
 rotation speeds up, which is extremely unlikely. The only ways
 that I can think of that happening would be either a volcano
 about to spew enough energy in the right direction and an
 asteroid hitting the earth with a glancing blow. Either would be
 catastrophic. It would be better to not remove a leapsecond and
 just wait for the next time a positive leapsecond adjustment is
 needed.

Danny

---

From: Doug Arnold <[email-masked]>
Date: Thu, 21 Oct 2021 19:18:57 +0000

Unless you are a member of the IERS, you don’t decide whether there is going to be a negative leap second or not.  I suggest that the rest of us focus on making sure that our products, or open source projects can handle a negative leap second.

All the more reason to make TAI the default timescale for NTPv5.

Doug

From: ntp <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Thursday, October 21, 2021 at 2:52 PM
To: James <[email-masked]>
Cc: NTP WG <[email-masked]>, Hal Murray <[email-masked]>, Danny Mayer <[email-masked]>
Subject: [Ntp] Antwort: Re: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
Yeah, sorry, I forgot to add that these weren't idle fears.
The earth rotation does appear to be speeding up right now, it is just a bit unclear whether or not it will *keep* doing it long enough for that negative leap second to become necessary.
If it does, it seems to also be uncertain whether the planned change will come in time to prevent it from being a thing operators have to deal with (since, as I said, the change likely won't be this decade).

Kristof

-----"James" <[email-masked]<mailto:[email-masked]>> schrieb: -----
An: "Danny Mayer" <[email-masked]<mailto:[email-masked]>>
Von: "James" <[email-masked]<mailto:[email-masked]>>
Datum: 21.10.2021 17:52
Kopie: [email-masked]<mailto:[email-masked]>, "Hal Murray" <[email-masked]<mailto:[email-masked]>>, "NTP WG" <[email-masked]<mailto:[email-masked]>>
Betreff: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

- J

On 21 Oct 2021, at 17:29, Danny Mayer <[email-masked]<mailto:[email-masked]>> wrote:
On 10/21/21 7:59 AM, [email-masked]<mailto:[email-masked]> wrote:
I only have second-hand insight, really.
What I gather is that there is a growing fear of a situation similar to the Y2K bug scare, because it is predicted that (for the first time I believe) there could soon be a negative leap second and time sync appliances might just fail in the face of having to deal with that.
I will try to get better info, in particular quantifying chances and timeframe.
The only way that is likely to happen is if the earth rotation speeds up, which is extremely unlikely. The only ways that I can think of that happening would be either a volcano about to spew enough energy in the right direction and an asteroid hitting the earth with a glancing blow. Either would be catastrophic. It would be better to not remove a leapsecond and just wait for the next time a positive leapsecond adjustment is needed.
Danny

_______________________________________________
ntp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ntp

---

From: Danny Mayer <[email-masked]>
Date: Thu, 21 Oct 2021 15:42:01 -0400

On 10/21/21 3:18 PM, Doug Arnold wrote:
>
> Unless you are a member of the IERS, you don’t decide whether there is 
> going to be a negative leap second or not.  I suggest that the rest of 
> us focus on making sure that our products, or open source projects can 
> handle a negative leap second.
>
I agree, but negative leapseconds is fraught with problems that really 
have never been addressed or tested in NTP (PTP testing of this showed a 
lot of problems).
> All the more reason to make TAI the default timescale for NTPv5.
No, the networked world expects UTC. GPS runs on TAI but then the 
satellites have atomic clocks.

Danny

---

From: Steve Allen <[email-masked]>
Date: Thu, 21 Oct 2021 12:49:48 -0700

> experienced (solar) time.

At the 2015 ITU-R WRC the original draft document had three options
for change of the way that UTC is defined.  When that draft was
circulated six nations objected and the final document of options
included a 4th option which was, paraphrased "You all have spent 15
years trying to redefine UTC and in all of that time none of the
documents provided for consideration have explained why leap seconds
exist nor the consequences for abandoning them; therefore do nothing."
The result of the 2015 WRC was nothing.

One problem is that most people, and the laws in most nations, expect
that a legal calendar day is determined by observing the rotation of
the earth.  In particular, the laws in many nations explicitly state
that legal time is mean solar days and/or GMT.  A purely atomic time
scale with no leap seconds is not mean solar time.  A "UTC" without
leap seconds would therefore not be legal in many places, and thus not
suitable for an international recommendation.

> kinda hope the solution is to increase the maximum difference to an hour,

The "leap hour" was proposed early in 21st century discussions by the
delgation from the USA.  It was ridiculed as even harder to enforce
and implement than the leap second, but at the time of that proposal
the legal time of the USA was explicitly based on GMT, therefore the
delegation from the USA could not legally submit a proposal that
called for UTC to deviate indefinitely from mean solar time.

The leap second exists in the first place because the old form of
atomically coordinated time which was the international agreement in
the 1960s had radio broadcasts of atomically-regulated seconds with a
duration longer than the SI second which was adopted in 1967.  Every
national metrology agency which adopted that old scheme was able to
broadcast time signals that agreed to within a millisecond.  Not every
nation adopted the old form of coordinated time; in particular the
Soviets never used it.

After the adoption of the SI second Germany passed a law which defined
all legal metrology in Germany to be based on SI units, and it changed
the national metrology agencies which were responsible for certifying
those measurements.  Responsibility for time in Germany was removed
from the longstanding hydrology institute which observed the sky and
given solely to PTB.  PTB decided that it would be illegal to
broadcast any kind of second other than the SI second, therefore in
less than two years Germany would no longer conform with the existing
international agreement for broadcast time signals.  That started a
scramble to forge a new international agreement which would be
acceptable everywhere.

Many meetings were ex parte, proceedings were not recorded (or even
redacted -- there is one international meeting which was annulled,
removed from offical history, and re-held a year later).  The final
tweaks to the agreement that was implemented were based on meeting
with a Soviet representative in order to get USSR to join, even though
those tweaks made it impossible to implement the agreement as it had
been approved by the CCIR.

It is clear they agreed that any new agreement must be legal in all
countries, therefore it must provide mean solar time.  Thus came the
leap second as a means of reaching a new acceptable consensus quickly,
without having to wait for most of the nations of the world to
redefine legal time, and without the risk that some nations might
legislate otherwise.

Among the documents that did survive was an IAU report which said that
leap seconds would be disastrous.  Its authors recognized that they
were being ignored in the haste to reach a new international
agreement, but also their position did not enable them to poison such
an agreement.  What they could and did do was to announce that the
operational radio navigation systems they controlled would be purely
atomic time without leap seconds, and that astronomical times would
continue to use Universal Time.  That need for two different time
scales was something that astronomers had recognized for decades
before the leap second, but which national laws still cannot grok.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Oct 2021 22:13:50 +0100

[email-masked] <[email-masked]> wrote:

> Yeah, sorry, I forgot to add that these weren't idle fears. The earth
> rotation does appear to be speeding up right now, it is just a bit
> unclear whether or not it will *keep* doing it long enough for that
> negative leap second to become necessary.

The best way I know of to get a rough indication of when the next leap
second might happen is using IERS Bulletin A. It contains predictions of
DUT1 for the next year, plus a simple equation that can be used for longer
term projections. It's basically a linear multiple of the current length
of day (less 24*60*60 seconds) plus some seasonal adjustment terms that
aren't relevant to the current discussion.

In the last few years, the Bulletin A estimated long-term LoD was longest
in June 2016 at +1470 µs. It dropped fairly steadily, eventually becoming
less than 86400 seconds in November last year. It stopped getting shorter
in May and is now gradually getting longer, but the LoD is still 220 µs
less than 24*60*60 s, which suggests there might be a negative leap second
in about 8 years, if things don't change, though they certainly will
change.

Here's some output from a program I wrote:

https://github.com/fanf2/bulletin-a

2020-01-02 -> 2023-06-30 (+) UT1-UTC -0.594 ± 0.053 s (lod +320 µs)
2020-01-09 -> 2023-06-30 (+) UT1-UTC -0.582 ± 0.053 s (lod +310 µs)
2020-01-16 -> 2023-06-30 (+) UT1-UTC -0.563 ± 0.053 s (lod +290 µs)
2020-01-23 -> 2023-06-30 (+) UT1-UTC -0.555 ± 0.053 s (lod +280 µs)
2020-01-30 -> 2023-12-31 (+) UT1-UTC -0.569 ± 0.058 s (lod +270 µs)
2020-02-06 -> 2024-06-30 (+) UT1-UTC -0.612 ± 0.063 s (lod +250 µs)
2020-02-13 -> 2024-06-30 (+) UT1-UTC -0.596 ± 0.063 s (lod +240 µs)
2020-02-20 -> 2024-06-30 (+) UT1-UTC -0.581 ± 0.063 s (lod +230 µs)
2020-02-27 -> 2024-06-30 (+) UT1-UTC -0.567 ± 0.063 s (lod +220 µs)
2020-03-05 -> 2024-06-30 (+) UT1-UTC -0.554 ± 0.063 s (lod +210 µs)
2020-03-12 -> 2024-06-30 (+) UT1-UTC -0.540 ± 0.062 s (lod +200 µs)
2020-03-19 -> 2025-06-30 (+) UT1-UTC -0.591 ± 0.073 s (lod +190 µs)
2020-03-26 -> 2025-06-30 (+) UT1-UTC -0.569 ± 0.073 s (lod +180 µs)
2020-04-02 -> 2025-06-30 (+) UT1-UTC -0.570 ± 0.072 s (lod +180 µs)
2020-04-09 -> 2025-06-30 (+) UT1-UTC -0.552 ± 0.072 s (lod +170 µs)
2020-04-16 -> 2025-06-30 (+) UT1-UTC -0.551 ± 0.072 s (lod +170 µs)
2020-04-23 -> 2025-06-30 (+) UT1-UTC -0.530 ± 0.072 s (lod +160 µs)
2020-04-30 -> 2026-06-30 (+) UT1-UTC -0.564 ± 0.082 s (lod +150 µs)
2020-05-07 -> 2026-06-30 (+) UT1-UTC -0.569 ± 0.082 s (lod +150 µs)
2020-05-14 -> 2026-06-30 (+) UT1-UTC -0.574 ± 0.081 s (lod +150 µs)
2020-05-21 -> 2026-06-30 (+) UT1-UTC -0.554 ± 0.081 s (lod +140 µs)
2020-05-28 -> 2026-06-30 (+) UT1-UTC -0.556 ± 0.081 s (lod +140 µs)
2020-06-04 -> 2026-06-30 (+) UT1-UTC -0.556 ± 0.081 s (lod +140 µs)
2020-06-11 -> 2026-06-30 (+) UT1-UTC -0.553 ± 0.081 s (lod +140 µs)
2020-06-18 -> 2026-06-30 (+) UT1-UTC -0.528 ± 0.080 s (lod +130 µs)
2020-06-25 -> 2026-06-30 (+) UT1-UTC -0.526 ± 0.080 s (lod +130 µs)
2020-07-02 -> 2026-06-30 (+) UT1-UTC -0.520 ± 0.080 s (lod +130 µs)
2020-07-09 -> 2027-06-30 (+) UT1-UTC -0.539 ± 0.090 s (lod +120 µs)
2020-07-16 -> 2028-06-30 (+) UT1-UTC -0.549 ± 0.099 s (lod +110 µs)
2020-07-23 -> 2028-06-30 (+) UT1-UTC -0.547 ± 0.099 s (lod +110 µs)
2020-07-30 -> 2028-06-30 (+) UT1-UTC -0.520 ± 0.099 s (lod +100 µs)
2020-08-06 -> 2028-06-30 (+) UT1-UTC -0.522 ± 0.098 s (lod +100 µs)
2020-08-13 -> 2029-06-30 (+) UT1-UTC -0.523 ± 0.107 s (lod +90 µs)
2020-08-20 -> 2029-06-30 (+) UT1-UTC -0.518 ± 0.107 s (lod +90 µs)
2020-08-27 -> 2030-06-30 (+) UT1-UTC -0.508 ± 0.116 s (lod +80 µs)
2020-09-03 -> 2031-06-30 (+) UT1-UTC -0.493 ± 0.125 s (lod +70 µs)
2020-09-10 -> 2031-06-30 (+) UT1-UTC -0.489 ± 0.124 s (lod +70 µs)
2020-09-17 -> 2032-06-30 (+) UT1-UTC -0.470 ± 0.133 s (lod +60 µs)
2020-09-24 -> 2033-06-30 (+) UT1-UTC -0.487 ± 0.141 s (lod +60 µs)
2020-10-01 -> 2034-06-30 (+) UT1-UTC -0.452 ± 0.149 s (lod +50 µs)
2020-10-08 -> 2037-06-30 (+) UT1-UTC -0.441 ± 0.173 s (lod +40 µs)
2020-10-15 -> 2040-06-30 (+) UT1-UTC -0.412 ± 0.195 s (lod +30 µs)
2020-10-22 -> 2045-06-30 (+) UT1-UTC -0.377 ± 0.231 s (lod +20 µs)
2020-10-29 -> 2045-06-30 (+) UT1-UTC -0.376 ± 0.231 s (lod +20 µs)
2020-11-05 -> 2054-06-30 (+) UT1-UTC -0.318 ± 0.292 s (lod +10 µs)
2020-11-12 -> ????-??-?? (?)
2020-11-19 -> ????-??-?? (?)
2020-11-26 -> 2158-12-31 (-) UT1-UTC +0.843 ± 0.841 s (lod -20 µs)
2020-12-03 -> 2073-12-31 (-) UT1-UTC +0.416 ± 0.411 s (lod -30 µs)
2020-12-10 -> 2053-12-31 (-) UT1-UTC +0.317 ± 0.288 s (lod -40 µs)
2020-12-17 -> 2048-12-31 (-) UT1-UTC +0.347 ± 0.255 s (lod -50 µs)
2020-12-24 -> 2042-12-31 (-) UT1-UTC +0.400 ± 0.212 s (lod -70 µs)
2020-12-31 -> 2040-12-31 (-) UT1-UTC +0.422 ± 0.198 s (lod -80 µs)
2021-01-07 -> 2037-12-31 (-) UT1-UTC +0.459 ± 0.175 s (lod -100 µs)
2021-01-14 -> 2035-12-31 (-) UT1-UTC +0.443 ± 0.159 s (lod -110 µs)
2021-01-21 -> 2033-12-31 (-) UT1-UTC +0.458 ± 0.143 s (lod -130 µs)
2021-01-28 -> 2033-12-31 (-) UT1-UTC +0.503 ± 0.142 s (lod -140 µs)
2021-02-04 -> 2031-12-31 (-) UT1-UTC +0.476 ± 0.125 s (lod -160 µs)
2021-02-11 -> 2031-12-31 (-) UT1-UTC +0.511 ± 0.125 s (lod -170 µs)
2021-02-18 -> 2030-12-31 (-) UT1-UTC +0.488 ± 0.116 s (lod -180 µs)
2021-02-25 -> 2030-12-31 (-) UT1-UTC +0.526 ± 0.116 s (lod -190 µs)
2021-03-04 -> 2030-06-30 (-) UT1-UTC +0.502 ± 0.111 s (lod -200 µs)
2021-03-11 -> 2029-12-31 (-) UT1-UTC +0.525 ± 0.107 s (lod -210 µs)
2021-03-18 -> 2029-12-31 (-) UT1-UTC +0.559 ± 0.107 s (lod -220 µs)
2021-03-25 -> 2028-12-31 (-) UT1-UTC +0.509 ± 0.097 s (lod -230 µs)
2021-04-01 -> 2028-12-31 (-) UT1-UTC +0.538 ± 0.097 s (lod -240 µs)
2021-04-08 -> 2028-12-31 (-) UT1-UTC +0.564 ± 0.097 s (lod -250 µs)
2021-04-15 -> 2028-12-31 (-) UT1-UTC +0.561 ± 0.097 s (lod -250 µs)
2021-04-22 -> 2028-06-30 (-) UT1-UTC +0.515 ± 0.092 s (lod -260 µs)
2021-04-29 -> 2028-06-30 (-) UT1-UTC +0.514 ± 0.092 s (lod -260 µs)
2021-05-06 -> 2028-06-30 (-) UT1-UTC +0.512 ± 0.091 s (lod -260 µs)
2021-05-13 -> 2028-12-31 (-) UT1-UTC +0.578 ± 0.096 s (lod -260 µs)
2021-05-20 -> 2028-12-31 (-) UT1-UTC +0.573 ± 0.096 s (lod -260 µs)
2021-05-27 -> 2028-12-31 (-) UT1-UTC +0.569 ± 0.096 s (lod -260 µs)
2021-06-03 -> 2028-12-31 (-) UT1-UTC +0.539 ± 0.095 s (lod -250 µs)
2021-06-10 -> 2028-12-31 (-) UT1-UTC +0.536 ± 0.095 s (lod -250 µs)
2021-06-17 -> 2028-12-31 (-) UT1-UTC +0.534 ± 0.095 s (lod -250 µs)
2021-06-24 -> 2028-12-31 (-) UT1-UTC +0.534 ± 0.095 s (lod -250 µs)
2021-07-01 -> 2028-12-31 (-) UT1-UTC +0.534 ± 0.095 s (lod -250 µs)
2021-07-08 -> 2028-12-31 (-) UT1-UTC +0.531 ± 0.094 s (lod -250 µs)
2021-07-15 -> 2028-12-31 (-) UT1-UTC +0.527 ± 0.094 s (lod -250 µs)
2021-07-22 -> 2028-12-31 (-) UT1-UTC +0.522 ± 0.094 s (lod -250 µs)
2021-07-29 -> 2029-06-30 (-) UT1-UTC +0.509 ± 0.099 s (lod -240 µs)
2021-08-05 -> 2029-06-30 (-) UT1-UTC +0.505 ± 0.098 s (lod -240 µs)
2021-08-12 -> 2029-06-30 (-) UT1-UTC +0.505 ± 0.098 s (lod -240 µs)
2021-08-19 -> 2029-12-31 (-) UT1-UTC +0.546 ± 0.103 s (lod -230 µs)
2021-08-26 -> 2029-12-31 (-) UT1-UTC +0.548 ± 0.103 s (lod -230 µs)
2021-09-02 -> 2029-12-31 (-) UT1-UTC +0.550 ± 0.102 s (lod -230 µs)
2021-09-09 -> 2029-12-31 (-) UT1-UTC +0.551 ± 0.102 s (lod -230 µs)
2021-09-16 -> 2029-12-31 (-) UT1-UTC +0.554 ± 0.102 s (lod -230 µs)
2021-09-23 -> 2029-12-31 (-) UT1-UTC +0.556 ± 0.102 s (lod -230 µs)
2021-09-30 -> 2029-12-31 (-) UT1-UTC +0.558 ± 0.102 s (lod -230 µs)
2021-10-07 -> 2029-12-31 (-) UT1-UTC +0.560 ± 0.102 s (lod -230 µs)
2021-10-14 -> 2029-12-31 (-) UT1-UTC +0.532 ± 0.101 s (lod -220 µs)
2021-10-21 -> 2029-12-31 (-) UT1-UTC +0.533 ± 0.101 s (lod -220 µs)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Lundy, Fastnet, Irish Sea: Southwest 6 or 7, increasing gale 8 at
times. Rough or very rough in Fastnet, otherwise moderate or rough,
occasionally very rough. Occasional rain. Good, occasionally poor.