Re: [LEAPSECS] article for Metrologia

[Poul-Henning Kamp]

Joseph Gwinn writes:
> On Sun, 30 Oct 2022 07:08:25 +, Poul-Henning Kamp wrote:

> The other ting to keep in mind is the immense existing codebase of 
> unix kernels et al, not to mention application code depending on 
> those kernels.

This is the mistake we IT-people keep doing again and again:

Forwards compatibility is /far/ more important than backwards compatibility.

For one thing, there is a finite amount of code to be backwards compatible with,
whereas the amount of future code is practically infinite.

Back in 1990 we had what, 30 years of legacy code for a quite small industry ?

Now we have that /and/ another 30 years of code produced by a vastly larger 
industry. 

"Immense existing codebase" ... not so much.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Joseph Gwinn]

On Sun, 30 Oct 2022 07:08:25 +, Poul-Henning Kamp wrote:
> 
> Warner Losh writes:
> 
>> The problem is time_t can't encode a leap second uniquely, but leap seconds
>> had been a thing for ~20 years when the first POSIX standards came out. It
>> was more of a willful choice to disregard them entirely as a simplification
>> than lack of clairvoyance.
> 
> I would say it is even worse:
> 
> POSIX was simply an administrative exercise to rapidly rubber-stamp
> the AT manuals to define a common baseline "before UNIX fragmented".
> 
> The "technical review" of POSIX amounted to "The seven dwarfs" comparing
> it to their own manuals, to ensure that their "me-too" UNIX could be made
> compliant with minimal effort.
> 
> Even if it had been a very convincing proposal, any change as
> fundamental as time_t, be it leap-seconds or 64 bits, would have
> been instantly shot down, entirely on the grounds that "The seven
> dwarfs" didn't have the in-house UNIX-skill to implement the change.

Not exactly.  I laid the history out in the "[time-nuts] Leap seconds 
and POSIX" thread circa 2009, which I won't recite here - see for 
instance 
.

The other ting to keep in mind is the immense existing codebase of 
unix kernels et al, not to mention application code depending on 
those kernels.

Joe Gwinn 
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Poul-Henning Kamp]

Warner Losh writes:

> The problem is time_t can't encode a leap second uniquely, but leap seconds
> had been a thing for ~20 years when the first POSIX standards came out. It
> was more of a willful choice to disregard them entirely as a simplification
> than lack of clairvoyance.

I would say it is even worse:

POSIX was simply an administrative exercise to rapidly rubber-stamp
the AT manuals to define a common baseline "before UNIX fragmented".

The "technical review" of POSIX amounted to "The seven dwarfs" comparing
it to their own manuals, to ensure that their "me-too" UNIX could be made
compliant with minimal effort.

Even if it had been a very convincing proposal, any change as
fundamental as time_t, be it leap-seconds or 64 bits, would have
been instantly shot down, entirely on the grounds that "The seven
dwarfs" didnt have the in-house UNIX-skill to implement the change.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Warner Losh]

On Sat, Oct 29, 2022, 11:49 AM Joseph Gwinn  wrote:

> General comment:
>
> The POSIX standards which unix and variants follow uses a string time
> format that looks like UTC, but is not, because leap seconds are
> never applied.  This was done precisely because an isolated unix box
> had no access to leap-second information; this was the norm in that
> day, long before networks and GPS.
>
> So, those faulty designers of yore had insufficient clairvoyance
> skills.
>

The problem is time_t can't encode a leap second uniquely, but leap seconds
had been a thing for ~20 years when the first POSIX standards came out. It
was more of a willful choice to disregard them entirely as a simplification
than lack of clairvoyance. At the time it didn't seem important but by the
late 90s the mistake was obvious to anybody who had to deliver a unix
system that pedanticly tracked time through a leapsecond or had to deal
with true UTC timestamps could attest... I found many rants in the early
2000s when I tried to ship my such system for LORAN-C timing system
refresh. It's the poster child in my mind for all the problems that I've
been mentioning that still aren't adequately addressed 20 years later.

Warner

Joe Gwinn
>
> On Sat, 29 Oct 2022 18:16:14 +0200, Steffen Nurpmeso wrote:
> > Warner Losh wrote in
> >  :
> >  |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso 
> >  |wrote:
> >  |> Steve Allen wrote in
> >  |>  <20221028045813.ga20...@ucolick.org>:
> >  |>|On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
> >  |>|> Levine, Tavella, and Milton have an upcoming article for Metrologia
> >  |>|> on the issue of leap seconds in UTC
> >  |>|>
> >  |>|> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
> >  |>|
> >  |>|sorry, stray character appended to my cut and paste
> >  |>|
> >  |>|
> >  |>
> >  |> That "increasing number of applications" all through the document
> >  |> makes me angry really.  I find it astonishing to read that there
> >  |> are digital clocks that cannot display a second 60 and all that.
> >  |> This is just another outcome of the trivialization and
> >  |> superficialication all around.  You need a reliable source of
> >  |> time, use TAI; or distribute the offset of UT1 and UTC
> >  |> permanently, best TAI, too.  so that changes can be detected.
> >
> > I mean yes, it may be that many languages provide a complete set
> > of functions, time spans and whatever is needed to deal with time
> > properly.  I have not really looked, and my C++ is as of pre Y2K,
> > more or less (but completely regarding the library that grew
> > enormously, that much i know).
> >
> > For plain ISO C there is nothing, and when you refer to the
> > "right" zoneinfo, then i cannot deal with this, let alone easily,
> > in a multithreaded environment, etc.
> > This is a miss of ISO C that should have been addressed maybe
> > already in the first real version beyond the labratory where it
> > was created, instead of beating onto Ritchie's nerves for mess.
> >
> >  |If you deal with time in TAI, then you must have a perfect source of
> leap
> >  |seconds due to the de-facto requirement that times be presented in UTC.
> >  |That's the biggest problem with using TAI + the 'right' files. If
> > you don't
> >  |know
> >  |the offset when the system starts, then fixing it later can be hard.
> >  |
> >  |The truth often is that UTC is available, and if you're very lucky, \
> >  |you have
> >  |a source of leap seconds that's in-band and as-reliable as UTC in a
> timely
> >  |manner. If you aren't lucky, then using TAI is a non-starter or
> requires
> >  |several orders of magnitude more effort to setup a distribution system
> of
> >  |it and you're often left with the conversion to UTC problem.
> >
> > Yes.  It was a design fault.  Why should machines be driven with
> > a time scale designed for human life?  Instead a machine time
> > should be distributed with the necessities to derive the (a) human
> > time from it.  But that ship has sailed with the satellites and
> > NTP.  So then a few bits have to be found to include the offset
> > permanently.  This could long have happened.  But changing a human
> > timescale to make badly designed machines happy, or only making
> > bad software happy that unrolls bad code because of missing
> > support in standard libraries.  I would not do this.
> >
> >
> >  |> Distribution of leap seconds into time and date applications is
> >  |> a problem.  Clock calculations with UNIX epoch are all wrong given
> >  |> the current semantics except in the current (leap) era.
> >  |> Does this change if leaps are removed in the future.  For the
> >  |> past.  We need a reliable clock, which is TAI to me, and we need
> >  |> the leap second table in order to generate graceful dates in the
> >  |> past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
> >  |> 2023-06-28 ... UTC.
> >  |
> >  |Yes. Having two time scales 

Re: [LEAPSECS] article for Metrologia

[Steve Allen]

On Sat 2022-10-29T13:48:19-0400 Joseph Gwinn hath writ:
> So, those faulty designers of yore had insufficient clairvoyance
> skills.

Not the fault of the designers.

The Time Lords who incepted leap seconds were caught between
conflicting legal requirements.  They had no choice, or rather, no
choice other than to risk becoming part of another another Ides of
March scenario in international timekeeping.  Their lack of choice
included preventing their dilemma from appearing in official
documents.  They knew that leap seconds were technically barren and
that no other legal option was possible to implement at that time.
This is why Winkler limited himself to paraphrasing Mr. Spock while
directing that the USNO navigational broadcast systems would shift
from old UTC to TAI-10.  The need for purely atomic time was evident
more than 50 years ago, but the ability to implement it correctly
was not yet technically possible.  So the principals guarded their
speech into their retirement and death rather than advocate that
the leap second scheme was necessarily temporary and would need to
be replaced by something better.

--
Steve Allen  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
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Steffen Nurpmeso]

Joseph Gwinn wrote in
 <20221029134819386898.e3c27...@comcast.net>:
 |General comment:
 |
 |The POSIX standards which unix and variants follow uses a string time 
 |format that looks like UTC, but is not, because leap seconds are 
 |never applied.  This was done precisely because an isolated unix box 
 |had no access to leap-second information; this was the norm in that 
 |day, long before networks and GPS.
 |
 |So, those faulty designers of yore had insufficient clairvoyance 
 |skills.

It came up here often, and POSIX itself writes it "has been
debated on a number of occasions", and "Those applications which
do care about leap seconds can determine how to handle them in
whatever way those applications feel is best."
So it says "POSIX.1-2017 do not take leap seconds into account
when computing seconds since the Epoch.", and

  Coordinated Universal Time (UTC) includes leap seconds. However,
  in POSIX time (seconds since the Epoch), leap seconds are
  ignored (not applied) to provide an easy and compatible method
  of computing time differences. Broken-down POSIX time is
  therefore not necessarily UTC, despite its appearance.

This is why you need other functions to be able to calculate time
spans and such correctly, and for that you need a machine oriented
base timer, and an offset.

Maybe funnily this week's Monday on source-changes-d@ of NetBSD

   ...
   |If you use a monotonic timer to sample the POSIX clock before and
   |after a leap second, the POSIX clock will appear to have taken twice
   |as long as it should to pass the leap second.

  Just to note that the next leap second could be a negative one.

I mean it does not make sense to look into the past.  Programmers
must be enabled to perform the correct calculations, and in my
personal opinion adjusting human time cannot be that.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Steffen Nurpmeso]

jimlux wrote in
 :
 |On 10/28/22 11:10 AM, Steffen Nurpmeso wrote:
 |> Steve Allen wrote in
 |>   <20221028045813.ga20...@ucolick.org>:
 |>|On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
 |>|> Levine, Tavella, and Milton have an upcoming article for Metrologia
 |>|> on the issue of leap seconds in UTC
 |>|>
 |>|> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
 |>|
 |>|sorry, stray character appended to my cut and paste
 |>|
 |>|https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
 |> 
 |> That "increasing number of applications" all through the document
 |> makes me angry really.  I find it astonishing to read that there
 |> are digital clocks that cannot display a second 60 and all that.
 |
 |The digital clock by my bedside, and a variety or other clocks that 
 |don't have computers in them don't display second 60, nor do they handle 
 |going from 58 to 00.

Yes.  That is how it mostly is ever since.  That is, i recall
a leap event shown in the Tagesschau news of German TV, red colour
on black from America .. Wall Street?  That turned to 60.

 |The clocks in my various and sundry appliances also do not do this.
 |
 |One can argue, who cares - whether the oven turns on a second early or 
 |late probably isn't a problem.

That i would argue for most of these clocks myself.  Even my
laptop that synchronizes via SNTP through rdate -a with an
always-on vserver that has NTP running, and which does
/sbin/hwclock --systohc --update-drift shortly before each "echo
mem > /sys/power/state" and before poweroff has to be adjusted
anywhere from -0.372340 to -0.916331 seconds on a new-days's first
sync.

 |But what about the enormous number of industrial process controllers - 
 |almost all of which do not deal with leap seconds.  At some point, sure, 
 |they'll sync, either by hand, or over the network.  And that's where it 
 |starts to get sticky.
 |
 |Do you smear or jump? If you're running a system where seconds count - 
 |radar is one example.  A plane moves several hundred meters/second. If 
 |you're tracking and sending position reports, do you transmit times in 
 |UTC or TAI?
 |
 |There's the possibility of cooperative traffic avoidance for cars, 
 |planes, and boats - The data is always late, so there's an element of 
 |modeling taking position and velocity at time t=x-Nseconds and 
 |propagating that forward to t=x.
 |
 |> This is just another outcome of the trivialization and
 |> superficialication all around.  You need a reliable source of
 |> time, use TAI; or distribute the offset of UT1 and UTC
 |> permanently, best TAI, too.  so that changes can be detected.  NTP
 |> does still not do it, does it.  (It is still not using DTLS but
 |> something else, too.  My one cent (again).)  You know how large
 |> these packets are?  Now that even refrigerators and light bulbs go
 |> online (and letting aside the privacy issues), it is all there, at
 |> your fingertips.  Sorry, i do not understand.
 |
 |It is precisely because there is a difference between UTC and TAI (or 
 |GPS) that changes, and that there is no "universal" way to handle the 
 |change that it is a problem.  Mission critical systems will tend to 
 |figure something out, but it might be different.
 |
 |I worked on SCaN Testbed [1] - a system that flew on ISS for a number of 
 |years. This inconsistency of intepretation of time (UTC, GMT, GPST, TAI) 
 |led us to implement a flight rule "Turn off the power 1 hour before the 
 |leap second and turn it on 1 hour after".  That was easier than trying 
 |to get everyone on the same page (everyone is a remarkably large crowd - 
 |experiment PIs, test controllers and engineers, payload operators, ISS 
 |controllers, ISS internal data bus time distribution (Broadcast 
 |Ancillary Data on MIL-STD-1553), not to mention the entire pipeline of 
 |data links up to and back down all the way to the ops center.

How terrible!

 |[1]R. C. Reinhart, T. J. Kacpura, S. K. Johnson and J. P. Lux, "NASA's 
 |space communications and navigation test bed aboard the international 
 |space station," in IEEE Aerospace and Electronic Systems Magazine, vol. 
 |28, no. 4, pp. 4-15, April 2013, doi: 10.1109/MAES.2013.6506824.

That is grazy.  Needs a sign-in for full reading.
Well i do not know obviously.  I would emit a steady thing and an
offset to human time, i think that i already said in the first
message to this list, about NTP, then.
But i would not make the human time scale that steady thing.

  ...

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Joseph Gwinn]

General comment:

The POSIX standards which unix and variants follow uses a string time 
format that looks like UTC, but is not, because leap seconds are 
never applied.  This was done precisely because an isolated unix box 
had no access to leap-second information; this was the norm in that 
day, long before networks and GPS.

So, those faulty designers of yore had insufficient clairvoyance 
skills.

Joe Gwinn

On Sat, 29 Oct 2022 18:16:14 +0200, Steffen Nurpmeso wrote:
> Warner Losh wrote in
>  :
>  |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso 
>  |wrote:
>  |> Steve Allen wrote in
>  |>  <20221028045813.ga20...@ucolick.org>:
>  |>|On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
>  |>|> Levine, Tavella, and Milton have an upcoming article for Metrologia
>  |>|> on the issue of leap seconds in UTC
>  |>|>
>  |>|> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
>  |>|
>  |>|sorry, stray character appended to my cut and paste
>  |>|
>  |>|
>  |>
>  |> That "increasing number of applications" all through the document
>  |> makes me angry really.  I find it astonishing to read that there
>  |> are digital clocks that cannot display a second 60 and all that.
>  |> This is just another outcome of the trivialization and
>  |> superficialication all around.  You need a reliable source of
>  |> time, use TAI; or distribute the offset of UT1 and UTC
>  |> permanently, best TAI, too.  so that changes can be detected.
> 
> I mean yes, it may be that many languages provide a complete set
> of functions, time spans and whatever is needed to deal with time
> properly.  I have not really looked, and my C++ is as of pre Y2K,
> more or less (but completely regarding the library that grew
> enormously, that much i know).
> 
> For plain ISO C there is nothing, and when you refer to the
> "right" zoneinfo, then i cannot deal with this, let alone easily,
> in a multithreaded environment, etc.
> This is a miss of ISO C that should have been addressed maybe
> already in the first real version beyond the labratory where it
> was created, instead of beating onto Ritchie's nerves for mess.
> 
>  |If you deal with time in TAI, then you must have a perfect source of leap
>  |seconds due to the de-facto requirement that times be presented in UTC.
>  |That's the biggest problem with using TAI + the 'right' files. If 
> you don't
>  |know
>  |the offset when the system starts, then fixing it later can be hard.
>  |
>  |The truth often is that UTC is available, and if you're very lucky, \
>  |you have
>  |a source of leap seconds that's in-band and as-reliable as UTC in a timely
>  |manner. If you aren't lucky, then using TAI is a non-starter or requires
>  |several orders of magnitude more effort to setup a distribution system of
>  |it and you're often left with the conversion to UTC problem.
> 
> Yes.  It was a design fault.  Why should machines be driven with
> a time scale designed for human life?  Instead a machine time
> should be distributed with the necessities to derive the (a) human
> time from it.  But that ship has sailed with the satellites and
> NTP.  So then a few bits have to be found to include the offset
> permanently.  This could long have happened.  But changing a human
> timescale to make badly designed machines happy, or only making
> bad software happy that unrolls bad code because of missing
> support in standard libraries.  I would not do this.
> 
> 
>  |> Distribution of leap seconds into time and date applications is
>  |> a problem.  Clock calculations with UNIX epoch are all wrong given
>  |> the current semantics except in the current (leap) era.
>  |> Does this change if leaps are removed in the future.  For the
>  |> past.  We need a reliable clock, which is TAI to me, and we need
>  |> the leap second table in order to generate graceful dates in the
>  |> past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
>  |> 2023-06-28 ... UTC.
>  |
>  |Yes. Having two time scales is a problem due to the need for perfect
>  |knowledge
>  |of both parts. given the current issues that persist in gaining 
> leap second
>  |knowledge, that makes TAI unreliable.
> 
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Steffen Nurpmeso]

Warner Losh wrote in
 :
 |On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso 
 |wrote:
 |> Steve Allen wrote in
 |>  <20221028045813.ga20...@ucolick.org>:
 |>|On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
 |>|> Levine, Tavella, and Milton have an upcoming article for Metrologia
 |>|> on the issue of leap seconds in UTC
 |>|>
 |>|> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
 |>|
 |>|sorry, stray character appended to my cut and paste
 |>|
 |>|https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
 |>
 |> That "increasing number of applications" all through the document
 |> makes me angry really.  I find it astonishing to read that there
 |> are digital clocks that cannot display a second 60 and all that.
 |> This is just another outcome of the trivialization and
 |> superficialication all around.  You need a reliable source of
 |> time, use TAI; or distribute the offset of UT1 and UTC
 |> permanently, best TAI, too.  so that changes can be detected.

I mean yes, it may be that many languages provide a complete set
of functions, time spans and whatever is needed to deal with time
properly.  I have not really looked, and my C++ is as of pre Y2K,
more or less (but completely regarding the library that grew
enormously, that much i know).

For plain ISO C there is nothing, and when you refer to the
"right" zoneinfo, then i cannot deal with this, let alone easily,
in a multithreaded environment, etc.
This is a miss of ISO C that should have been addressed maybe
already in the first real version beyond the labratory where it
was created, instead of beating onto Ritchie's nerves for mess.

 |If you deal with time in TAI, then you must have a perfect source of leap
 |seconds due to the de-facto requirement that times be presented in UTC.
 |That's the biggest problem with using TAI + the 'right' files. If you don't
 |know
 |the offset when the system starts, then fixing it later can be hard.
 |
 |The truth often is that UTC is available, and if you're very lucky, \
 |you have
 |a source of leap seconds that's in-band and as-reliable as UTC in a timely
 |manner. If you aren't lucky, then using TAI is a non-starter or requires
 |several orders of magnitude more effort to setup a distribution system of
 |it and you're often left with the conversion to UTC problem.

Yes.  It was a design fault.  Why should machines be driven with
a time scale designed for human life?  Instead a machine time
should be distributed with the necessities to derive the (a) human
time from it.  But that ship has sailed with the satellites and
NTP.  So then a few bits have to be found to include the offset
permanently.  This could long have happened.  But changing a human
timescale to make badly designed machines happy, or only making
bad software happy that unrolls bad code because of missing
support in standard libraries.  I would not do this.


 |> Distribution of leap seconds into time and date applications is
 |> a problem.  Clock calculations with UNIX epoch are all wrong given
 |> the current semantics except in the current (leap) era.
 |> Does this change if leaps are removed in the future.  For the
 |> past.  We need a reliable clock, which is TAI to me, and we need
 |> the leap second table in order to generate graceful dates in the
 |> past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
 |> 2023-06-28 ... UTC.
 |
 |Yes. Having two time scales is a problem due to the need for perfect
 |knowledge
 |of both parts. given the current issues that persist in gaining leap second
 |knowledge, that makes TAI unreliable.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Michael Wouters]

Hello Demetrios

It’s Open Access, since the intent is to have it widely read.Similarly,
upcoming papers on the proposed redefinition of the second will also be
Open Access.

Cheers
Michael


On Sat, 29 Oct 2022 at 1:56 pm, Demetrios Matsakis via LEAPSECS <
leapsecs@leapsecond.com> wrote:

> I agree with these comments, but I think the paper isn’t out yet and fear
> it will be behind the Metrologia paywall when it does come out.  But that’s
> ok because I see Judah Levine of NIST is a coauthor.  That’s good.  I like
> to say that everyone should have a NIST coauthor because their papers are
> not subject to copyright plus they get placed on their web site. (Of
> course, there are other reasons too.)
>
> You might be interested in this presentation I gave at the CGSIC last
> month, entitled “Will we have a negative leap second”:
> https://www.gps.gov/cgsic/meetings/2022/matsakis.pdf
>
> > On Oct 28, 2022, at 7:15 PM, jimlux  wrote:
> >
> > On 10/28/22 11:10 AM, Steffen Nurpmeso wrote:
> >> Steve Allen wrote in
> >>  <20221028045813.ga20...@ucolick.org>:
> >>  |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
> >>  |> Levine, Tavella, and Milton have an upcoming article for Metrologia
> >>  |> on the issue of leap seconds in UTC
> >>  |>
> >>  |> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
> >>  |
> >>  |sorry, stray character appended to my cut and paste
> >>  |
> >>  |https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
> >> That "increasing number of applications" all through the document
> >> makes me angry really.  I find it astonishing to read that there
> >> are digital clocks that cannot display a second 60 and all that.
> >
> > The digital clock by my bedside, and a variety or other clocks that
> don't have computers in them don't display second 60, nor do they handle
> going from 58 to 00.
> >
> > The clocks in my various and sundry appliances also do not do this.
> >
> > One can argue, who cares - whether the oven turns on a second early or
> late probably isn't a problem.
> >
> > But what about the enormous number of industrial process controllers -
> almost all of which do not deal with leap seconds.  At some point, sure,
> they'll sync, either by hand, or over the network.  And that's where it
> starts to get sticky.
> >
> > Do you smear or jump? If you're running a system where seconds count -
> radar is one example.  A plane moves several hundred meters/second. If
> you're tracking and sending position reports, do you transmit times in UTC
> or TAI?
> >
> > There's the possibility of cooperative traffic avoidance for cars,
> planes, and boats - The data is always late, so there's an element of
> modeling taking position and velocity at time t=x-Nseconds and propagating
> that forward to t=x.
> >
> >
> >
> >
> >> This is just another outcome of the trivialization and
> >> superficialication all around.  You need a reliable source of
> >> time, use TAI; or distribute the offset of UT1 and UTC
> >> permanently, best TAI, too.  so that changes can be detected.  NTP
> >> does still not do it, does it.  (It is still not using DTLS but
> >> something else, too.  My one cent (again).)  You know how large
> >> these packets are?  Now that even refrigerators and light bulbs go
> >> online (and letting aside the privacy issues), it is all there, at
> >> your fingertips.  Sorry, i do not understand.
> >
> >
> > It is precisely because there is a difference between UTC and TAI (or
> GPS) that changes, and that there is no "universal" way to handle the
> change that it is a problem.  Mission critical systems will tend to figure
> something out, but it might be different.
> >
> > I worked on SCaN Testbed [1] - a system that flew on ISS for a number of
> years. This inconsistency of intepretation of time (UTC, GMT, GPST, TAI)
> led us to implement a flight rule "Turn off the power 1 hour before the
> leap second and turn it on 1 hour after".  That was easier than trying to
> get everyone on the same page (everyone is a remarkably large crowd -
> experiment PIs, test controllers and engineers, payload operators, ISS
> controllers, ISS internal data bus time distribution (Broadcast Ancillary
> Data on MIL-STD-1553), not to mention the entire pipeline of data links up
> to and back down all the way to the ops center.
> >
> > [1]R. C. Reinhart, T. J. Kacpura, S. K. Johnson and J. P. Lux, "NASA's
> space communications and navigation test bed aboard the international space
> station," in IEEE Aerospace and Electronic Systems Magazine, vol. 28, no.
> 4, pp. 4-15, April 2013, doi: 10.1109/MAES.2013.6506824.
> >
> >> And _i_ do not want to hear "o-ho-ho, but there is a difference in
> >> between solar time and the time zone anyhow", there is
> >> a difference also in between a priest and a wise man, and you
> >> better conform to the former or they kill you.  Really.
> >> (I would never let temples be driven by engineers, not even if
> >> they are permanently joined by their 

Re: [LEAPSECS] article for Metrologia

[Steve Allen]

On Fri 2022-10-28T22:55:54-0400 Demetrios Matsakis via LEAPSECS hath writ:
> You might be interested in this presentation I gave at the CGSIC
> last month, entitled “Will we have a negative leap second”:
> https://www.gps.gov/cgsic/meetings/2022/matsakis.pdf

compare
https://www.ucolick.org/~sla/leapsecs/seasonal.html

Is it not the case that references to the 19 year Metonic cycle
should be references to the 18.6 year Draconic cycle?

--
Steve Allen  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
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Demetrios Matsakis via LEAPSECS]

I agree with these comments, but I think the paper isn’t out yet and fear it 
will be behind the Metrologia paywall when it does come out.  But that’s ok 
because I see Judah Levine of NIST is a coauthor.  That’s good.  I like to say 
that everyone should have a NIST coauthor because their papers are not subject 
to copyright plus they get placed on their web site. (Of course, there are 
other reasons too.)

You might be interested in this presentation I gave at the CGSIC last month, 
entitled “Will we have a negative leap second”: 
https://www.gps.gov/cgsic/meetings/2022/matsakis.pdf

> On Oct 28, 2022, at 7:15 PM, jimlux  wrote:
> 
> On 10/28/22 11:10 AM, Steffen Nurpmeso wrote:
>> Steve Allen wrote in
>>  <20221028045813.ga20...@ucolick.org>:
>>  |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
>>  |> Levine, Tavella, and Milton have an upcoming article for Metrologia
>>  |> on the issue of leap seconds in UTC
>>  |>
>>  |> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
>>  |
>>  |sorry, stray character appended to my cut and paste
>>  |
>>  |https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
>> That "increasing number of applications" all through the document
>> makes me angry really.  I find it astonishing to read that there
>> are digital clocks that cannot display a second 60 and all that.
> 
> The digital clock by my bedside, and a variety or other clocks that don't 
> have computers in them don't display second 60, nor do they handle going from 
> 58 to 00.
> 
> The clocks in my various and sundry appliances also do not do this.
> 
> One can argue, who cares - whether the oven turns on a second early or late 
> probably isn't a problem.
> 
> But what about the enormous number of industrial process controllers - almost 
> all of which do not deal with leap seconds.  At some point, sure, they'll 
> sync, either by hand, or over the network.  And that's where it starts to get 
> sticky.
> 
> Do you smear or jump? If you're running a system where seconds count - radar 
> is one example.  A plane moves several hundred meters/second. If you're 
> tracking and sending position reports, do you transmit times in UTC or TAI?
> 
> There's the possibility of cooperative traffic avoidance for cars, planes, 
> and boats - The data is always late, so there's an element of modeling taking 
> position and velocity at time t=x-Nseconds and propagating that forward to 
> t=x.
> 
> 
> 
> 
>> This is just another outcome of the trivialization and
>> superficialication all around.  You need a reliable source of
>> time, use TAI; or distribute the offset of UT1 and UTC
>> permanently, best TAI, too.  so that changes can be detected.  NTP
>> does still not do it, does it.  (It is still not using DTLS but
>> something else, too.  My one cent (again).)  You know how large
>> these packets are?  Now that even refrigerators and light bulbs go
>> online (and letting aside the privacy issues), it is all there, at
>> your fingertips.  Sorry, i do not understand.
> 
> 
> It is precisely because there is a difference between UTC and TAI (or GPS) 
> that changes, and that there is no "universal" way to handle the change that 
> it is a problem.  Mission critical systems will tend to figure something out, 
> but it might be different.
> 
> I worked on SCaN Testbed [1] - a system that flew on ISS for a number of 
> years. This inconsistency of intepretation of time (UTC, GMT, GPST, TAI) led 
> us to implement a flight rule "Turn off the power 1 hour before the leap 
> second and turn it on 1 hour after".  That was easier than trying to get 
> everyone on the same page (everyone is a remarkably large crowd - experiment 
> PIs, test controllers and engineers, payload operators, ISS controllers, ISS 
> internal data bus time distribution (Broadcast Ancillary Data on 
> MIL-STD-1553), not to mention the entire pipeline of data links up to and 
> back down all the way to the ops center.
> 
> [1]R. C. Reinhart, T. J. Kacpura, S. K. Johnson and J. P. Lux, "NASA's space 
> communications and navigation test bed aboard the international space 
> station," in IEEE Aerospace and Electronic Systems Magazine, vol. 28, no. 4, 
> pp. 4-15, April 2013, doi: 10.1109/MAES.2013.6506824.
> 
>> And _i_ do not want to hear "o-ho-ho, but there is a difference in
>> between solar time and the time zone anyhow", there is
>> a difference also in between a priest and a wise man, and you
>> better conform to the former or they kill you.  Really.
>> (I would never let temples be driven by engineers, not even if
>> they are permanently joined by their wifes.)
>> To me it remains a cultural achievement that we can track the
>> offset so exactly, and this cultural achievement is practically
>> shared by a lot of human cultures (if you want to grant these
>> beasts such, especially the west, goodness, gracious, great balls
>> of fire!), as many of them have a relation to the sun (the big LED
>> / infrared thing on the blue screen, 

Re: [LEAPSECS] article for Metrologia

[jimlux]

On 10/28/22 11:10 AM, Steffen Nurpmeso wrote:

Steve Allen wrote in
  <20221028045813.ga20...@ucolick.org>:
  |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
  |> Levine, Tavella, and Milton have an upcoming article for Metrologia
  |> on the issue of leap seconds in UTC
  |>
  |> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
  |
  |sorry, stray character appended to my cut and paste
  |
  |https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5

That "increasing number of applications" all through the document
makes me angry really.  I find it astonishing to read that there
are digital clocks that cannot display a second 60 and all that.


The digital clock by my bedside, and a variety or other clocks that 
don't have computers in them don't display second 60, nor do they handle 
going from 58 to 00.


The clocks in my various and sundry appliances also do not do this.

One can argue, who cares - whether the oven turns on a second early or 
late probably isn't a problem.


But what about the enormous number of industrial process controllers - 
almost all of which do not deal with leap seconds.  At some point, sure, 
they'll sync, either by hand, or over the network.  And that's where it 
starts to get sticky.


Do you smear or jump? If you're running a system where seconds count - 
radar is one example.  A plane moves several hundred meters/second. If 
you're tracking and sending position reports, do you transmit times in 
UTC or TAI?


There's the possibility of cooperative traffic avoidance for cars, 
planes, and boats - The data is always late, so there's an element of 
modeling taking position and velocity at time t=x-Nseconds and 
propagating that forward to t=x.






This is just another outcome of the trivialization and
superficialication all around.  You need a reliable source of
time, use TAI; or distribute the offset of UT1 and UTC
permanently, best TAI, too.  so that changes can be detected.  NTP
does still not do it, does it.  (It is still not using DTLS but
something else, too.  My one cent (again).)  You know how large
these packets are?  Now that even refrigerators and light bulbs go
online (and letting aside the privacy issues), it is all there, at
your fingertips.  Sorry, i do not understand.



It is precisely because there is a difference between UTC and TAI (or 
GPS) that changes, and that there is no "universal" way to handle the 
change that it is a problem.  Mission critical systems will tend to 
figure something out, but it might be different.


I worked on SCaN Testbed [1] - a system that flew on ISS for a number of 
years. This inconsistency of intepretation of time (UTC, GMT, GPST, TAI) 
led us to implement a flight rule "Turn off the power 1 hour before the 
leap second and turn it on 1 hour after".  That was easier than trying 
to get everyone on the same page (everyone is a remarkably large crowd - 
experiment PIs, test controllers and engineers, payload operators, ISS 
controllers, ISS internal data bus time distribution (Broadcast 
Ancillary Data on MIL-STD-1553), not to mention the entire pipeline of 
data links up to and back down all the way to the ops center.


[1]R. C. Reinhart, T. J. Kacpura, S. K. Johnson and J. P. Lux, "NASA's 
space communications and navigation test bed aboard the international 
space station," in IEEE Aerospace and Electronic Systems Magazine, vol. 
28, no. 4, pp. 4-15, April 2013, doi: 10.1109/MAES.2013.6506824.




And _i_ do not want to hear "o-ho-ho, but there is a difference in
between solar time and the time zone anyhow", there is
a difference also in between a priest and a wise man, and you
better conform to the former or they kill you.  Really.
(I would never let temples be driven by engineers, not even if
they are permanently joined by their wifes.)

To me it remains a cultural achievement that we can track the
offset so exactly, and this cultural achievement is practically
shared by a lot of human cultures (if you want to grant these
beasts such, especially the west, goodness, gracious, great balls
of fire!), as many of them have a relation to the sun (the big LED
/ infrared thing on the blue screen, you know).

Distribution of leap seconds into time and date applications is
a problem.  Clock calculations with UNIX epoch are all wrong given
the current semantics except in the current (leap) era.
Does this change if leaps are removed in the future.  For the
past.  We need a reliable clock, which is TAI to me, and we need
the leap second table in order to generate graceful dates in the
past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
2023-06-28 ... UTC.

Just my one cent.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com

Re: [LEAPSECS] article for Metrologia

[Warner Losh]

On Fri, Oct 28, 2022 at 12:11 PM Steffen Nurpmeso 
wrote:

> Steve Allen wrote in
>  <20221028045813.ga20...@ucolick.org>:
>  |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
>  |> Levine, Tavella, and Milton have an upcoming article for Metrologia
>  |> on the issue of leap seconds in UTC
>  |>
>  |> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
>  |
>  |sorry, stray character appended to my cut and paste
>  |
>  |https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5
>
> That "increasing number of applications" all through the document
> makes me angry really.  I find it astonishing to read that there
> are digital clocks that cannot display a second 60 and all that.
> This is just another outcome of the trivialization and
> superficialication all around.  You need a reliable source of
> time, use TAI; or distribute the offset of UT1 and UTC
> permanently, best TAI, too.  so that changes can be detected.


If you deal with time in TAI, then you must have a perfect source of leap
seconds due to the de-facto requirement that times be presented in UTC.
That's the biggest problem with using TAI + the 'right' files. If you don't
know
the offset when the system starts, then fixing it later can be hard.

The truth often is that UTC is available, and if you're very lucky, you have
a source of leap seconds that's in-band and as-reliable as UTC in a timely
manner. If you aren't lucky, then using TAI is a non-starter or requires
several orders of magnitude more effort to setup a distribution system of
it and you're often left with the conversion to UTC problem.


> Distribution of leap seconds into time and date applications is
> a problem.  Clock calculations with UNIX epoch are all wrong given
> the current semantics except in the current (leap) era.
> Does this change if leaps are removed in the future.  For the
> past.  We need a reliable clock, which is TAI to me, and we need
> the leap second table in order to generate graceful dates in the
> past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
> 2023-06-28 ... UTC.
>

Yes. Having two time scales is a problem due to the need for perfect
knowledge
of both parts. given the current issues that persist in gaining leap second
knowledge, that makes TAI unreliable.

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Steffen Nurpmeso]

Steve Allen wrote in
 <20221028045813.ga20...@ucolick.org>:
 |On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
 |> Levine, Tavella, and Milton have an upcoming article for Metrologia
 |> on the issue of leap seconds in UTC
 |>
 |> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b
 |
 |sorry, stray character appended to my cut and paste
 |
 |https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5

That "increasing number of applications" all through the document
makes me angry really.  I find it astonishing to read that there
are digital clocks that cannot display a second 60 and all that.
This is just another outcome of the trivialization and
superficialication all around.  You need a reliable source of
time, use TAI; or distribute the offset of UT1 and UTC
permanently, best TAI, too.  so that changes can be detected.  NTP
does still not do it, does it.  (It is still not using DTLS but
something else, too.  My one cent (again).)  You know how large
these packets are?  Now that even refrigerators and light bulbs go
online (and letting aside the privacy issues), it is all there, at
your fingertips.  Sorry, i do not understand.

And _i_ do not want to hear "o-ho-ho, but there is a difference in
between solar time and the time zone anyhow", there is
a difference also in between a priest and a wise man, and you
better conform to the former or they kill you.  Really.
(I would never let temples be driven by engineers, not even if
they are permanently joined by their wifes.)

To me it remains a cultural achievement that we can track the
offset so exactly, and this cultural achievement is practically
shared by a lot of human cultures (if you want to grant these
beasts such, especially the west, goodness, gracious, great balls
of fire!), as many of them have a relation to the sun (the big LED
/ infrared thing on the blue screen, you know).

Distribution of leap seconds into time and date applications is
a problem.  Clock calculations with UNIX epoch are all wrong given
the current semantics except in the current (leap) era.
Does this change if leaps are removed in the future.  For the
past.  We need a reliable clock, which is TAI to me, and we need
the leap second table in order to generate graceful dates in the
past.  Here it is usr/share/zoneinfo/leapseconds, and it expires
2023-06-28 ... UTC.

Just my one cent.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Steve Allen]

On Thu 2022-10-27T19:25:01-0700 Steve Allen hath writ:
> Levine, Tavella, and Milton have an upcoming article for Metrologia
> on the issue of leap seconds in UTC
>
> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b

sorry, stray character appended to my cut and paste

https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5

--
Steve Allen  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
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] article for Metrologia

[Warner Losh]

On Thu, Oct 27, 2022 at 8:25 PM Steve Allen  wrote:

> Levine, Tavella, and Milton have an upcoming article for Metrologia
> on the issue of leap seconds in UTC
>
> https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b



"We are sorry, that page has not been found..."

Is that because I don't have creds, or is this link bad?

Warner


>
> --
> Steve Allen  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
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] article for Metrologia

[Steve Allen]

Levine, Tavella, and Milton have an upcoming article for Metrologia
on the issue of leap seconds in UTC

https://iopscience.iop.org/article/10.1088/1681-7575/ac9da5b

--
Steve Allen  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
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs