Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
On 1/16/19 12:31 AM, Poul-Henning Kamp wrote: In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes: On Tue 2019-01-15T12:34:11-0800 Gary E. Miller hath writ: Yes, and no. time_t is just seconds since an epoch. Which epoch is not well defined. The epoch may well be anything. See "man difftime". That evokes a challenge for all time nuts that I can make based on reading Bulletin Horaire. What is the epoch that was used for TAI? Isn't that the same one Loran-C used ? 1958-01-01 00:00:00 GMT ? You might be thinking of CCSDS Unsegmented Time - in the header of the time message you specify what the epoch is - It's either the 1958 (beginning of "space age") or "user defined" Similar for CCSDS Day Segmented Code which is 16 or 24 bits of days after epoch, milliseconds, and (optional) submilliseconds They also clone the ISO UTC called ASCII Calendar Segmented Time Code - -MM-DDThh:mm:ss.ddZ as well as DOY versions, etc. They manage the leapsecond with a 58 or 61 second minute. It's also clear that CCSDS doesn't like non-continuous, non-monotonic time scales: " f) Standardization on the use of these time code formats for purposes OTHER than identifying an instant of calendar or time in UTC (e.g., unconventional use as a counter or tool for measuring arbitrary intervals) is not recommended. It is felt such a specialized application can best be viewed not as a time code format but rather as an engineering measurement format. Any such application of these time code formats is considered beyond the scope of this Recommended Standard. " https://public.ccsds.org/Pubs/301x0b4e1.pdf "The CCSDS-Recommended epoch is that of 1958 January 1 (TAI) and the recommended time unit is the second, using TAI as reference time scale, for use as a level 1 time code. This time code is not UTC-based and leap-second corrections do not apply." Bit1-3 =Time code identification 001 — 1958 January 1 epoch (Level 1 Time Code) 010 — Agency-defined epoch (Level 2 Time Code) Level 1 in CCSDS means "complete and unambiguous interpretation", Level 2 means "you need some other information" ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
On 1/15/19 11:41 AM, Rob Seaman wrote: Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The various libraries and operating systems listed deal with none of the reference time scales (GPS, UTC, or TAI, for that matter) completely and correctly. There's no obvious connection here with astronomical use cases. We rely on our reference clocks' vendor to have implemented IS-GPS-200J and relevant standards correctly. These devices operate off single board linux cards, but I presume they wrote the critical code themselves to handle leap seconds, but also other precision timekeeping issues not entertained by POSIX and other mass market software. Our clocks handle time scales other than UTC, but since our customer (NASA PDCO) specifies UTC, that's what we deliver. The bread-and-butter leap second discussions on this list seem irrelevant to simply meeting an engineering requirement to adhere to whatever standard. If POSIX, python, excel, whatever don't provide canned tools to convert seamlessly between GPS and UTC, or to handle format conversions from week:ms to sexagesimal, such tools must be implemented outside those languages/libraries. There are a vast number of other science-related data engineering details that POSIX (for example) also does not implement. Indeed - but before leaping[sic] into coding it up, I thought I'd ask around You also asked.. > /I'll probably test it for the cases I'm interested in (Ruby, Python, > Excel, Matlab, Octave), but if someone else has already done it, then > I've got something to cross check against./ I would add MySQL/MariaDB and PostgreSQL, as well as TCL and C/C++ to that list. If JPL were to support libraries implementing some useful subset of timekeeping utilities under a smorgasbord of such languages, members of this list would undoubtedly be delighted to cross-check the results and put them to good use (via GitHub or what have you). --- I don't know that JPL is interested in a generalized library collection. It would be useful.. a sort of "cross platform" collection.. At JPL we tend to just solve the problem at hand, and release just that software. --- That said, it isn't clear what the original use case involves. Something about spacecraft using GPS week numbers and ground systems using UTC? But what do you need to do exactly? And is this onboard or on the ground? --- The use case is this - I have a satellite in orbit which does everything internally in terms of GPS week and millisecond of week. Folks on the ground work in UTC, since that's what the plethora of PCs are using. We want to synchronize an event on the ground with an event on the spacecraft, so, given that someone on the ground is going to do something on 21 January 2019 at 12:34:56Z, we need to be able to command the spacecraft to do that at the corresponding Week:Second. Right now, they use a website For example: https://www.labsat.co.uk/index.php/en/gps-time-calculator which, by the way, doesn't use leap seconds, so it's off by some 18 seconds Sometimes cross checked for consistency by, say, the page at http://leapsecond.com/java/gpsclock.htm It would be much easier for the operators if they could just *enter* the UTC time, and have the software calculate the GPS Week:millisecond (or vice versa) Leap Seconds, should they occur, would be handled by "don't do anything around or across the leap second". And, we could rebaseline the conversion i.e. the calculation would be SecondsAfterBaseDate = Seconds(UserEnteredDate) - Seconds(BaseDate) DesiredTime = Seconds(6 Jan 1980) + SecondsAfterBaseDate GPSWeek = Floor(DesiredTime/(86400*7)) GPSMilliseconds = (DesiredTime - GPSWeek*86400*7) * 1000 Which works quite nicely as long as the interval between BaseDate and UserEnteredDate does not include a leap second. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
On 1/15/19 6:34 PM, Rob Seaman wrote: Hi Jim, The use case is this - I have a satellite in orbit which does everything internally in terms of GPS week and millisecond of week. Folks on the ground work in UTC, since that's what the plethora of PCs are using. Just to verify. The satellite does use GPS as its reference clock, not some manual upload (in a similar way as you describe) from ground stations? The routines you're talking about aren't (directly) affecting the state of the clock on the spacecraft? Ground processing only - for user convenience Or more simply, how accurate are the satellite's GPS week and millisecond values? Time is set by the messages from the OEM-6xx series GPS receiver and its 1pps - It's GPS time, not UTC. if there's a GPS outage, time propagates forward on the onboard oscillator which isn't great. When GPS resumes, time jumps. We want to synchronize an event on the ground with an event on the spacecraft, so, given that someone on the ground is going to do something on 21 January 2019 at 12:34:56Z, we need to be able to command the spacecraft to do that at the corresponding Week:Second. Right now, they use a website For example: https://www.labsat.co.uk/index.php/en/gps-time-calculator which, by the way, doesn't use leap seconds, so it's off by some 18 seconds Do they ignore the 18 seconds? What precision is required for this application? I think the folks at the labsat website just coded a naive implementation. For this application, <1 second uncertainty is needed (technically, one can set events to occur to within 1 microsecond, but that's counted down from the 1pps using the internal clock, with the "correct" 1pps done by knowing it's week:second) Sometimes cross checked for consistency by, say, the page at http://leapsecond.com/java/gpsclock.htm It would be much easier for the operators if they could just *enter* the UTC time, and have the software calculate the GPS Week:millisecond (or vice versa) Leap Seconds, should they occur, would be handled by "don't do anything around or across the leap second". Or could you simply forbid activities during a few hours of June 30 / December 31? If the operators are at JPL this would be late afternoon on whatever day of the week. That is, just assume there's always a leap second at each opportunity. As it happens the ops aren't at JPL for this spacecraft. And that's exactly how we can deal with it - it's perfectly reasonable to say "folks, there's a leap second a'coming, run for the hills til it gets here" For spacecraft flying via JPL ops, we work in TAI (or also, MET - Mission Elapsed Time or SCLK - spacecraft clock), since all the nav is done that way.. we also have to deal with relativistic effects and light time - the whole "what do you do with time" on that scale has seen 40 years of development. And, we could rebaseline the conversion i.e. the calculation would be SecondsAfterBaseDate = Seconds(UserEnteredDate) - Seconds(BaseDate) DesiredTime = Seconds(6 Jan 1980) + SecondsAfterBaseDate GPSWeek = Floor(DesiredTime/(86400*7)) GPSMilliseconds = (DesiredTime - GPSWeek*86400*7) * 1000 Which works quite nicely as long as the interval between BaseDate and UserEnteredDate does not include a leap second. This conversion is so simple it seems unnecessary to rely on somebody else's library. What you might need is to arrange for a local, reliable, vetted copy of the leap seconds table. So perhaps folks here could comment on their best practices for retrieving same in an operational environment? or just set up an operational procedure that defines some file or something under configuration control that has the "GPS time" and the "Week:seconds" for the same time that is "after the last leap second". Note that if your use cases include retroactive requirements then even if leap seconds cease you will need to maintain the leap seconds table (perhaps compiled into the source through some date). (For leap second warriors, redefining UTC makes it more complicated, not less, when all use cases are considered.) Not really - for those kinds of use cases there's already issues and solutions with reconciling local observations of clocks against outside time scales. the "don't operate during the leap" and "keep track" work just fine. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
On 1/15/19 4:19 PM, Hal Murray wrote: The trick is to find a source that will set a POSIX system to TAI, and then to avoid the gotchas that happen when such a system interacts with other POSIX systems. What do the systems that point telescopes use for maintaining their system clock? Do they use NTP or a special program that listens to GPS or a local Hydrogen maser or ...? Some GPSDOs have the option to return GPS time rather than UTC. GPS is a fixed offset from TAI. So it's easy to run your system on TAI. All it takes is a little sysadmin hacking, no programming. You won't easily get redundancy from checking with other NTP servers. If you have several friends running similar systems, you could set up a private NTP network. With some work it would be reasonable to setup a ntp server that took in UTC but gave out TAI. That would be similar to the way leap smearing works. We could use a separate port number to minimize confuzion. As far as I know, the kernel doesn't know anything about what type of time it is maintaining. It just sets the clock as directed and goes tick, tick, tick. The trouble is with the time conversion routines. They all assume a time_t is UTC. So if you ran your system on TAI, all your log files would be off by 37 seconds. How hard would it be to insert a wrapper in front of the time conversion routines? The idea is to rename all the current time conversion routines from foo to foo_utc and implement foo_tai that concerts between UTC and TAI. It would need a list of leap seconds. The default implementation of foo would call foo_utc but an environment variable or such would switch to using foo_tai. Some modules (Python skyfield package from Rhodes Mill) explicitly deal with this. The time object has a method for each time scale.. These return utc in various formats time.utc_jpl() time.utc_iso() time.utc_datetime() These return other timescales time.tai time.tt time.J time.ut1 I confess I have used them blindly without checking, but I can do that quickly. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services
On 2/13/20 5:46 AM, Richard Langley wrote: "(i) Within 180 days of the date of this order, the Secretary of Commerce shall make available a GNSS-independent source of Coordinated Universal Time, to support the needs of critical infrastructure owners and operators, for the public and private sectors to access." https://www.whitehouse.gov/presidential-actions/executive-order-strengthening-national-resilience-responsible-use-positioning-navigation-timing-services/ Interesting that this has a 180 day "make available" but the other stuff in the EO (PNT profiles, etc) is years down the road. As a practical matter, this has already been done. WWV, WWVH, and WWVB all provide coordinated universal time without GNSS. The EO says nothing about accuracy, precision or availability. In fact, the dial up service (https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwv/telephone-time-day-service) would also work. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services
On 2/13/20 6:47 AM, Seaman, Robert Lewis - (rseaman) wrote: Conceivably Ruth Belville might satisfy the language: https://en.wikipedia.org/wiki/Ruth_Belville#/media/File:Ruth_Belville_1908.jpg Assuming Ms. Belville (or her successors) set their watches appropriately, yes. And it would be a private entrepreneurial provider, which conforms to other directives to seek out commercial providers of services. I believe though, that Ms. Belville significantly antedates UTC, as well as Betty White (1922) and sliced bread as a product (1928). ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] copy of UK report on public consultation?
On 4/27/20 4:58 AM, BASTIAN Michelle wrote: Hi all, I’m wondering if anyone has a copy of the report from the UK public dialogue on leap seconds that happened in 2014/2015 or so? The government website has a broken link unfortunately.. https://www.gov.uk/government/news/report-on-findings-of-uk-public-dialogue-on-leap-seconds Really appreciate any help with this. Best, Michelle. You might try here: https://participedia.net/case/5681 or here: https://s3.amazonaws.com/uploads.participedia.xyz/12201c1d-7c4d-4549-b1fc-146db6a77d37_EvaluationReportLeapsecondsevaluationreportMay15.pdf --- Dr Michelle Bastian Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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] LOD reaches 0 s/d
On 11/12/20 3:45 PM, Poul-Henning Kamp wrote: predicts that d(UT2)/d(TAI) = 1 after 2021-11-13, ie the rates of UTT2 and TAI are expected to agree for the next year. This has never happened since 1961. We may not need to abolish leap seconds for quite a while. Unless of course we get close enough to a negative one, that people are *really* going to freak out. Hands in the air: Who here besides Warner and me has ever tried to test handling of negative leap-seconds ? not exactly leap seconds, but I had a system that ingested time from two sources that were nominally synced, and one slipped behind - it was a gruesome disaster. Time going backwards creates ALL sorts of problems with log files and locking schemes and telemetry decoding/plotting that assume that time is monotonically increasing. (we leave, aside, the whole daylight time issue - that's a "print formatting of time values" thing. It fills me with great trepidation if clock time were ever to go backwards. I think what would happen is that people would hack it and have it sort of run slowly over some seconds, while maintaining monotonicity. And then create tiger teams to fix it when someone else did it differently, and your financial system ingested transactions that appeared to end before they started. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
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] leap minute or hour
On 11/15/22 1:34 PM, Poul-Henning Kamp wrote: Demetrios Matsakis via LEAPSECS writes: Another one, about traffic accidents, showed a whole bunch of wiggles = over a year, and said that one of those coincided with a DST switch. That one is actually pretty well documented in Europe, but most of the extra accidents are wildlife-strikes. Transpires that wildlife adapts to our rythm of life, but do not get the memo that tomorrow rush-hour will be one hour different. The contrary argument is for little kids out trick or treating on Oct 31. DST means it's not as dark at 7PM-ish. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] speeding up again?
On 6/15/23 10:50 PM, Poul-Henning Kamp wrote: Tom Van Baak writes: Steve, > We can probably put a lot of the blame onto El Niño That sounds plausible but I'm suspicious of quick and simple explanations. I dont think the primary El Niño phenomena involves enough mass transport to measurably change the angular momentum. It is mostly just a vertical inversion phenomena, which changes the evaporation from the sea surface. It has far ranging secondary effects, but those are mostly orthogonal to the rotation, so their effect is also attenuated. What I wonder is if anybody has done the angular rotation math on major forrest fires ? They convert a lot of trees from rigidly rotating surface mass to gasses, but I have no idea what the total incinerated mass might be... pretty small, compared to say, snow or ice. The ice melting in Antarctica and Greenland is much larger mass wise than mass of trees burned (and of course, most of the mass stays fixed, the blackened trees remain) If we estimate based on the CO2 release - the wildfires in CA are estimated to have released about 127 megatonnes in 2020 along (came across this in an article saying it's frustrating, because for all the work in green house gas reduction, CA had reduced their emissions by 65 megatonnes over 18 years) https://www.latimes.com/california/story/2022-10-20/california-wildfires-offset-greenhouse-gas-reductions But only 12/44ths of that is carbon that used to be fixed to the Earth surface - so a bit less than 35 megatonnes of carbon. OTOH, there's also hydrogen in those plants, etc. And on a annual time scale, soil moisture is probably a larger mass - after all, let's say that the average annual rainfall is on the order of 50cm everywhere, so that's 1/2 tonne/square meter. The US is about a gigahectare, so 10 terasquare meters, or 5 teratonnes of water. That's quite a bit more than the mass from all those Canadian fires, I suspect. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
