[LEAPSECS] article for Metrologia

Steffen Nurpmeso steffen at sdaoden.eu
Sat Oct 29 13:51:10 EDT 2022


jimlux wrote in
 <cf4c5e3e-ba36-5285-3959-26e07252d2d3 at earthlink.net>:
 |On 10/28/22 11:10 AM, Steffen Nurpmeso wrote:
 |> Steve Allen wrote in
 |>   <20221028045813.GA20487 at 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)


More information about the LEAPSECS mailing list