Re: [LEAPSECS] article for Metrologia
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
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
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
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
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
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
