Re: [LEAPSECS] negative leap second in 2029?
On Sat 2024-03-30T16:03:30-0700 Paul Hirose hath writ: > "Even a few years ago, the expectation was that leap seconds would always be > positive, and happen more and more often," Duncan Agnew, a geophysicist at The paper in Nature takes a very narrow view of history. Agnew looks only at data in IERS C04. That started in 1962 because 1) There were no available atomic time scales until the middle of year 1961, so earlier earth rotation data were less precise https://www.ucolick.org/~sla/leapsecs/taiepoch.html 2) The IAU had resolved that 1962-01-01 would be the date to change from using the FK3 star catalog to using the FK4 star catalog, and as noted in my TAI web page above that caused a discontinuity in the value of time. 3) Although coordinated time existed before, it was 1962-01-01 when BIH Paris was put in charge of what they would later name UTC. 4) The early atomic time scales from BIH were computed entirely by hand. The published values show arithmetic errors which were never corrected. With BIH perennially understaffed going back farther in time would incorporate more such errors into C04. With C04 there is only one point at which the core of the earth made one of its huge shifts in angular momentum, and that was coincidentally right around 1972. Agnew further restricts his analysis to only the earth rotation after 1972. Agnew is certainly correct that melting ice caps are slowing the rotation of the surface of the earth. With the acceleration being caused by whatever the core has been doing for the past 50 year Agnew is also correct that the meltwater is delaying the need for a negative leap second. But the analysis by Agnew is blind to the long history of big changes in the core. I think that is why Matsakis is quoted in one of the news articles about not betting on predictions of earth rotation. Also do not forget McCarthy and Matsakis previously looking at the trend https://insidegnss.com/will-we-have-a-negative-leap-second/ -- 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] UT1 offset
On Thu 2023-12-28T09:23:30+ Poul-Henning Kamp hath writ: > Also: When celestial navigation is possible, most vessels > travel a lot further than 50 meters during the time it takes to make > a measurement of the necessary precision. As noted by ION https://www.ion.org/Museum/item_view.cfm?cid=6=5=29 "Modern sextants can read the angle to a 0.1 minute level of accuracy" and older sextants to more like 0.5 arcminute. The best navigator under the best circumstances might get to within 0.1 nautical mile. More typical accuracy in actual use was several arcminutes or several nautical miles. When a sextant was used to shoot the moon to determine time half an arcminute accuracy means one time minute accuracy which is 15 arcminutes of longitude, so longitudes in mid-ocean could be off by many nautical miles. Frank Reed teaches the old techniques and if the opportunity presents itself I highly recommend taking his classes. https://reednavigation.com Few living astronomers have held a sextant in hand to shoot stars and the moon. I have, but during my lifetime has grown as disconnect between theory and practice. Some who are responsible for the tabulations in the almanacs are not facile with those techniques. Frank Reed taught me that the reason navigators did not like changes to the almanacs was because the reduction of a lunar was basically a ritual. Navigators did not know the nitty gritty of the celestial mechanics, but they did know a sequence of operations with the almancs which would produce a valid position. The instructional manuals for navigators still teach the equator and equinox and Greenwich meridian, but the equinox was abolished entirely by the IAU in 2003. The values tabulated in the almanacs had ceased to represent those original concepts a century before that, but a navigator who used the tabulations in the almanacs in the classical fashion would still compute a correct result. Gary Miller recently noted that navigators do not know about the existence of DUT1. I suspect that may be because the calculations are no longer being performed according to the ritual found in the old log books of ships. If the calculations are now performed by machines that are connected to telecom systems then all of the nitty gritty details like DUT1 are probably in the computer. -- 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] UT1 offset
On Mon 2023-12-25T00:25:07-0800 Hal Murray hath writ: > Who uses DUT1 via radio? Who will be using it 50 years from now? > > Is it needed for anything other than navigation and astronomy? UT1 is not needed for navigation if the almanacs switch their tabulations to use the time scale that is available. This was true 70 years ago. Navigators hate changes to the almanacs. 70 years ago the astronomers who made the almanacs preferred to maintain a Ptolemaic world view in part to avoid presenting a change to the navigators, in part to avoid having to prove that a different scheme of tabulation would be reliably correct and do all the new calculations still largely by hand, but most of all because their other job was to provide legal time, and legal time was based on mean solar time. -- 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] prep for WRC 23
This week began the meeting of ITU-R WRC 23. One preparation for this meeting was a document issued early this year The future of Coordinated Universal Time https://www.itu.int/en/itunews/Documents/2023/2023-02/2023_ITUNews02-en.pdf This looks at the use of time in several arenas, many of which would like UTC to stop having leap seconds. Many also allow that keeping agreement with the earth in the long run is necessary, and that they have no idea how to do that. -- 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] speeding up again?
On Mon 2023-05-22T16:44:30+0200 Tony Finch hath writ: > The prospect of a negative leap second is receding. The longer-term > projected length of day from Bulletin A has been increasing towards 24h > in recent months. We can probably put a lot of the blame onto El Niño -- 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] smear
On Mon 2023-03-20T19:36:51+ Michael Deckers via LEAPSECS hath writ: > � This seems to be lenient enough to allow for not scheduling > � a negative leap second even in the case that the difference > � (UT1 - UTC) should go a bit below -1 s before 2035. And today in the NTP working group mail list we see that the big guns expect to force the issue because > From: Doug Arnold > Subject: Re: [Ntp] draft-ntp-ntpv5-requirements update for IETF 116 > > Re leap smearing: > > Operators from multiple data centers tell me that they intend to > smear leap seconds. When I pointed out the pitfalls they were > undeterred. I have come to understand that leap smearing is viewed as > less problematic than trying to fix leap second handing in distributed > database software. they have taken the stance that if leap seconds do not go away then they will smear. This is like Eucla Australia setting their clocks the way they please and daring the state government to do something about it. -- 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] USNO predictions of UT1-UTC
On Mon 2023-03-20T00:55:26+ Seaman, Robert Lewis - (rseaman) hath writ: > Much consternation will be feigned. I will be making much use of the Michael Jackson eating popcorn gif -- 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] USNO predictions of UT1-UTC
On Sun 2023-03-19T19:24:56-0400 Demetrios Matsakis via LEAPSECS hath writ: > https://insidegnss.com/will-we-have-a-negative-leap-second/ > Will We Have a Negative Leap Second? The USNO predictions in IERS Bulletin A have been pretty good... https://www.ucolick.org/~sla/leapsecs/bulla52w.html It will be interesting to see what kind of consternation arises if the predictions start saying the negative leap is impending. Somewhere in USNO/UKHO somebody has been making longer term predictions for use in the navigational almanacs, but as far as I know those have never been published. -- 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] leap seconds in the not so news
today in leap second clickbait https://supplycloset.supplies/2022/12/04/scientists-killed-the-leap-second-your-birthday-could-be-next/ Scientists Killed The Leap Second. Your Birthday Could Be Next. -- 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] King Charles
On Sun 2022-12-04T16:30:01+ Tony Finch hath writ: > So if you agree with Donald Sadler, has already GMT concluded. I do agree, and I also disagree, for Sadler and was in large part responsible for another tacit change to GMT. Like others engaged in the present redefinitions, given his job Sadler could not have dared to describe the consequences of that in plain language. -- 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] King Charles
On Fri 2022-11-25T00:20:11+ Robert Jones hath writ: > GMT will probably be redefined yet again as it was in 1925 when noon was no > longer the start of the day and when leap seconds were introduced. 'When I use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean--neither more nor less.' 'The question is,' said Alice, 'whether you CAN make words mean so many different things.' 'The question is,' said Humpty Dumpty, 'which is to be master-- that's all.' -- 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] King Charles
It was King Charles II who oversaw the inception of GMT. If King Charles III lives as long as his mother then he will oversee the conclusion of GMT. -- 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] Global timekeepers vote to scrap leap second by 2035
On Sun 2022-11-20T13:23:32+ Kevin Birth hath writ: > As far as I can tell, they were never successful, but it did keep them busy. As Rod Serling wrote in The Big Tall Wish You got to believe, Bolie. But worse, because in this arena infidels will not be tolerated. -- 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] Alanna Mitchell in NYT
On Mon 2022-11-14T23:44:54+ Michael Deckers via LEAPSECS hath writ: > The reason why the CIPM (for now) sticks to the requirement that > |UTC - UT1| be bounded is most probably the argument brought forward > by some people from ISO who say that, without explicit bound on > |UTC - UT1|, UTC had to change its name so that "polysemy" is avoided. The funny part there is that UT1 does not mean what they think it means. -- 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] leap minute or hour
On Mon 2022-11-14T21:22:27+ Poul-Henning Kamp hath writ: > I doubt the will manage to convince the other 99+% to do something > as deranged as a leap-minute. > Thanks to timezones and DST, less than 1% of the worlds population > live where mean solar time is correct to a minute. The reason we got leap seconds in the first place is that one country changed its law so that the rubber/elastic seconds of original UTC became illegal. Even though they were advised of serious technical problems the other countries capitulated to leap seconds as the "parfaitement recommandable" solution to the political problem. We do not have Hari Seldon theory to guage the psychohistory of international alliances and how they will align with each other about answering "What time is it?" -- 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] Alanna Mitchell in NYT
On Mon 2022-11-14T18:27:25+ Poul-Henning Kamp hath writ: > And with a 2035 deadline we might just get to see if our implementations > of negative leap-seconds work before it is too late. > > Yes, it should have happened 20 years ago. I believe I recently saw PHK ruminating that forward compatibility in computing is at least as important as backward compatibility because the next 30 years of software need to know where they are going. The NYT article ends with Arias ruminating about how someday there will have to be a leap minute or leap hour. To have systems which will handle that eventuality we need to be openly considering the goals and implementation for that already. -- 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] Alanna Mitchell in NYT
Starting tomorrow the CGPM meets in Paris. Resolution D says leap seconds must die. CGPM will almost certainly approve that resolution. https://www.nytimes.com/2022/11/14/science/time-leap-second.html -- 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
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
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
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
[LEAPSECS] article for Metrologia
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
Re: [LEAPSECS] The Variable Earth’s Rotation in the 4th–7th Centuries: New ΔT Constraints,from Byzantine Eclipse Records
On Sun 2022-09-18T23:43:59-0400 Brooks Harris hath writ: > The Variable Earth’s Rotation in the 4th–7th Centuries: New ΔT Constraints > from Byzantine Eclipse Records > https://iopscience.iop.org/article/10.1088/1538-3873/ac6b56/pdf Very nice. The old eclipse observations are very scarce and the decadal fluctuations can take the value of Delta T far askew. It takes a lot of work to recognize the useful descriptions. The authors clearly also wanted to typset Amharic. -- 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] fb/meta join the leap second haters
On Tue 2022-07-26T20:42:03-0400 Brooks Harris hath writ: > Can anyone elaborate on what these 'decadal variations' may be? What they are is power in the spectrum of LOD at periods of decades that has been visible in the relatively good data from the past two centuries and which contributed to the inclusion of "non-gravitational" terms in the planetary theories of Newcomb and the lunar theories of Hill and Brown. Why they happen is harder to say since they probably originate in the weather of the core of the earth, but maybe not. See this Journees 2019 paper saying it may be crustal motion and ice https://syrte.obspm.fr/astro/journees2019/journees_pdf/SessionIV_2/SIDORENKOV_Nikolay.pdf Also in there that the earth had been getting less oblate, more spherical, through around year 2000 but maybe now is getting more oblate https://syrte.obspm.fr/astro/journees2019/journees_pdf/SessionIV_1/LIU_JiaCheng.pdf -- 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] fb/meta join the leap second haters
On Tue 2022-07-26T23:33:15+ Poul-Henning Kamp hath writ: > So looking at the IERS LOD plot going all the way back it seems to > me that we have been missing the big signal for about five decades: > > > https://datacenter.iers.org/singlePlot.php?plotname=EOPC04_14_62-NOW_IAU2000A-LOD=224 > > How did we not notice that earlier ? even better is the view from the Paris bureau at https://hpiers.obspm.fr/eop-pc/index.php which at the moment is showing a Vondrak filtering of the data with the predictable tidal terms removed. Even better would be to remove the UT2 semi/annual variation. caveat is that plot may change before you all look at it. The rotation of the earth's crust started accelerating right when the CCIR decided that we should start using leap seconds. karma -- 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] fb/meta join the leap second haters
Anyone with a twitter stream can see that Meta/Facebook have blogged that they want leap seconds to stop https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/ This is referenced in more and more tech publications like CNET https://www.cnet.com/tech/computing/tech-giants-try-banishing-the-leap-second-to-stop-internet-crashes/ The CNET article includes a quote from correspondence which repeats a trick that has been performed since the 1960s, that being to produce a significant underestimate of the difference between solar and atomic time by saying that the absence of leap seconds will not be noticed for 2000 years. -- 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] IGS 2022 leap second statement
On Wed 2022-07-06T15:09:42-0400 John Sauter via LEAPSECS hath writ: > I hope everyone noticed that the IERS issued Bulletin D 142 today, > which raises DUT1 from -0.1 to 0 as of July 28. In a less public forum on May 22 the International GNSS Service recommended that no more leap seconds be added to UTC https://files.igs.org/pub/resource/IGS_LeapSecond_Statement_Final.pdf -- 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] podcast from Orolia
Orolia has a 17 minute podcast about leap seconds https://www.orolia.com/place-and-time-episode-3-the-leap-second-on-trial/ -- 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] URSI speaks
URSI resolved about leap seconds https://www.ursi.org/Publications/RadioScienceLetters/Volume3/RSL21-0047-final.pdf It includes yet another passive voice redacted history of why they were implemented. -- 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] Never mind DUT1, what happened to dX ?
On Tue 2022-03-08T15:30:37+ Tony Finch hath writ: > (note that the coefficient is seconds _shorter_ than 24*60*60µss, > so +0.00021 means the long-term average LoD is 24h-210µs) Ah, that points out what may be a cool correlation. Looking back at dX and dY over their relatively short history it may be the case that the celestial pole position wobble around the predictable position is smaller when the rotation is accelerating. -- 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] problems with early TAI
Becker had a lot of opinions about atomic time, and he laid out the pictures of just how bad things were. Note figures 4 and 5 https://onlinelibrary.wiley.com/doi/epdf/10.1002/phbl.19830390302 Those show how the rate of TA(BIH) was way off as of the 1969 rearrangement that did not attempt to constrain the frequency of the new scale, and they show just how much the lack of air conditioning in the USNO clock house was messing up the HP units. Those artifacts of rate problems affect TAI forever inasmuch as they mean that the supposed 1958 origin and the actual 1961 origin do not correspond to the number of elapsed SI seconds in the value of TAI. -- 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] Never mind DUT1, what happened to dX ?
On Mon 2022-03-07T06:57:02+ Poul-Henning Kamp hath writ: > I'm not talking about the two spikes, I'm talking about the oscillation > disappearing, > and that seems to be in all the data sources ? ah, yes. I think we need another nutation cycle worth of high precision data, but I suspect nothing unusual is happening. -- 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] Never mind DUT1, what happened to dX ?
On Mon 2022-03-07T06:33:31+ Poul-Henning Kamp hath writ: > I looked at the Bulletin A plots this morning to see how DUT1 is > developing, but then I noticed the 'dX' term plot: > > > https://datacenter.iers.org/singlePlot.php?plotname=BulletinA_All-DX=6 > > What happened in late 2019 ? 2019 October is when USNO had to take their machines offline due to new security requirements. Those artifacts do not show at the ObsPM site https://hpiers.obspm.fr/eop-pc/index.php?index=analysis=en -- 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] Unsung Science with David Pogue
Leap Seconds, Smear Seconds, and the Slowing of the Earth as seen at https://unsungscience.com/the-podcast/ with the half-hour podcast available through many of the places that host podcasts. Comes to a near end just past halfway through after the assertion of what IAU and CGPM said, that leap seconds are the perfect solution, then abruptly continues about how that did not turn out to be true. Near the end are sound snips from the 2015 ITU WRC delegates deciding not to decide. -- 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] 256-week / leap seconds / in the news
On Sun 2021-07-25T09:47:24-0700 Tom Van Baak hath writ: > Per the GPS ICD, when dt_LS == dt_LSF there is no leap second to speak of; > not in recent past; not in near future. The 8-bit WN and DN fields are not > applicable to a non event. I see this as one example of the problem of handling NULL in an API and all the layers of software that use that API. POSIX (and many other interfaces, not just about time) supposes that it is always possible for the system to give a value for the time now. On social media recently I saw a weather app showing a temperature of 0 degF for a place that is not freezing. In the observatory control software that runs telescopes and instruments at Keck and Lick the overall system allows the concept of NULL, but not all of the underlying layers of code can handle NULL. Software in general, and programmers, should be prepared to handle the (hopefully) exceptional events when the answer to "What time is it?" is "I do not know" or "Here is a value but I cannot confirm that it is valid." For time in particular it has always been the case that the answer is "Here is a value that you can use for now, but if you want to compare it with the value deemed as correct by other systems and required by regulations you will have to check back later using another interface." -- 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] 256-week / leap seconds / in the news
On Sat 2021-07-24T18:50:50-0700 Tom Van Baak hath writ: > In the news: > > "GPS will broadcast a 0 second leap second in 128 days" > https://news.ycombinator.com/item?id=27944776 A tweet from Leo Bodnar electronics about their NTP device https://twitter.com/LeoBodnar/status/1419239590532206597 which famously includes highlighted text from the section of the GPS ICD that describes the need to do modulo arithmetic along with the URL to the new version of the firmware. -- 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] 256-week / leap seconds / in the news
On Sat 2021-07-24T18:50:50-0700 Tom Van Baak hath writ: > First, there really isn't a thing called a "0 leap second", but if you've > read the GPS ICD wrt leap seconds, you can see why it was posted. Second, it > happened once before, in 2003. "Modulo arithmetic class is tough" -- Barbie -- 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] Judah Levine of NIST
On Wed 2021-03-31T20:55:05-0700 Steve Allen hath writ: > Judah Levine has begun a multi-part essay > Everyday Time and Atomic Time > https://nist.medium.com/everyday-time-and-atomic-time-part-one-9107b60fd9d0 Part 2 on music and frequency https://nist.medium.com/everyday-time-and-atomic-time-part-2-65bb74d04f50 Part 3 the slippery slope of mean solar time https://nist.medium.com/everyday-time-and-atomic-time-part-3-24421c7a8c0f -- 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] Judah Levine of NIST
Judah Levine has begun a multi-part essay Everyday Time and Atomic Time https://nist.medium.com/everyday-time-and-atomic-time-part-one-9107b60fd9d0 -- 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] leap seconds, newspapers, earth rotation
On Wed 2021-01-06T10:36:10-0800 Tom Van Baak hath writ: > Does anyone know who started it? Is there a way to track it down? I am pretty sure that it started when some reporter meandered over to timeanddate.com and then started writing a followup. They have had a running dashboard showing just how long each day has been according to the IERS bureau predictions and keeping a sports statistics page on how the earth is doing. They ran a year end article looking over the stats https://www.timeanddate.com/time/earth-faster-rotation.html -- 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] Bulletin C number 60
On Tue 2020-07-07T22:38:59+0100 Tony Finch hath writ: > The LOD is hovering around 0 and the UT1-UTC chart is looking remarkably > flat. > > https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-UT1-UTC-BULA=9 > > https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-LOD-BULA=9 The earth has accelerated so that it is spinning as fast as it was during World War 2, and before that, the 1890s. -- 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] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services
On Thu 2020-02-13T14:37:32+ Richard Langley hath writ: > https://www.gpsworld.com/gps-backup-demonstration-projects-explained/ Crossing over a thread from time-nuts, the Wildwood eLoran should turn on its transmitter some time this week. -- 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] Leap seconds have a larger context than POSIX
In the late 1960s German radio station DCF77 did not broadcast time signals 24 hours a day. Different agencies controlled different signals at different times of day. Deutsches Hydrographisches Institut broadcast signals based on old UTC using their measurements of UT2 and the BIH offsets. PTB broadcast signals of stepped atomic time based on cesium seconds that became the SI second. On Wed 2020-02-05T17:59:31+ Michael Deckers hath writ: >The law on legal units in West Germany, from 1969-07-02, lists under >the title "tasks of the Physikalisch-Technische Bundesanstalt" >that the PTB has to publicize the procedures by which units without >material prototype are realized, including the units of time and >time scales, as well as the temperature unit and temperature scales. > hat die Verfahren bekanntzumachen, nach denen nicht verkörperte > Einheiten, einschließlich der Zeiteinheiten und der Zeitskalen > sowie der Temperatureinheit und Temperaturskalen, dargestellt > werden,") >This can be taken to imply the task to disseminate a standard >frequency (which they already did). But in my opinion it does not >imply that UTC must have the same rate as the atomic time scales >at the time -- the law even allows for several time scales. What this means is that DHI was out of the legal time business, and only PTB got to say what legal time was in Germany. The head of PTB said only SI seconds. -- 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] Leap seconds have a larger context than POSIX
On Wed 2020-02-05T15:32:54-0800 Tom Van Baak hath writ: > I'm not sure it's fundamental to TAI that one must always, or only, use > 24x60x60 radix notation. That's a useful convention in many cases, but at > the h/w counter or s/w binary integer level radix notation is not required. There were discussions about this in the early 1970s among members of the CCDS and CIPM. The USNO had been preferring a decimal count of seconds, and this notion is pretty much what ended up in GPS. Other members had other preferences, but in the end they made no decision. > Code should allow for a leap second event at the end of any month. The June > / December thing is one of several guidelines for BIPM; it's not a rule that > anyone writing UTC code should assume or depend on. Nor should code ever > assume leap seconds are positive. But the Soviets very much wanted not just any month, and they had previously been using their own form of non-BIH UT2 for their own different non-BIH rubber second UTC before 1972, and that looks like why the CCIR directed BIH to issue the leap second 1972-12-31T23:59:60 early and exceed the 0.7 s limit. Clearly the Soviets are no longer in a position to insist again, but this whole arena seems well described by Hector Barbossa telling Elizabeth Swan that the Pirate Code is more like guidelines than actual rules. Welcome abord the Black Pearl. -- 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] Leap seconds have a larger context than POSIX
I have a growing bibliography with references that show the rush toward atomic time was already underway at the 3rd CCDS meeting in 1963. At that meeting the delegates restricted themselves merely to ask CGPM12 to authorize an atomic SI second before CGPM13. The first time that the 4th meeting of the CCDS happened was in 1966, but that meeting is not found in any official record. The meeting ended with a vote to recommend that the CGPM should adopt an SI second based on cesium, but the circumstances of that vote were deemed so abusive that the entire meeting was nullified. That did not stop the rush for an atomic second. During the next year subsets of the CCDS members gathered for discussions at other meetings. When the second 4th meeting of the CCDS was held in 1967 they did recommend the cesium second to the CGPM. With that the push had turned to getting all radio broadcast time signals to use the cesium second. Proponents of the cesium second made demonstrably unrealistic presentations that minimized the difference that would accumulate between Atomic Time and Universal Time. When the issues were presented to agencies they recognized the tension between the need to broadcast atomically-regulated seconds and the need to provide earth rotation time used by navigators. The recommendations from several agencies were to involve other agencies in gathering together to study the problem. In 1968 delegates heading toward the next meeting of CCIR Working Party 7 gathered beforehand during a different meeting. There could be no proceedings from that gathering, but an offhand remark in a later report indicates they agreed that constructing a calendar out of SI seconds would require forging an international agreement. Altogether the meeting results were painting a picture that involved many agencies comprised of many people and many countries, and also much time to figure out a reasonable way to broadcast time using SI seconds. Folks at the PTB took a different aim by introducing draft legislation that the German government passed in 1969. The law made it illegal for the German government to broadcast anything other than SI seconds, and it would become effective in 1970. This seems to have pulled the trigger on the CCIR process, for without some kind of quick action a major nation would be broadcasting time signals using a different scale than other nations. Contributions and responses to questions from around 1969 make it clear that some technical agencies were unaware of the political constraints, and some bureaucratic agencies were unaware of the technical constraints. Several memoirs make it likely that H.M. Smith performed Herculean efforts to contain this dumpster fire of spreading incomplete information and forge a final agreement which was minimally objectionable to all parties. In my home state of California the process that led to UTC with leap seconds would have been illegal under the Brown Act that requires public access to meetings. But in the full context that is not the most criminal aspect of the process that led to the 1970 CCIR decision. After WW2 ended the ITU held a months-long meeting at Atlantic City in 1947 to discuss how recent advancements in radio technology would affect international agreements for use of radio broadcasts. The 1947 proceedings include reports from many national agencies on the history and technology of time determination and dissemination. The result is an encyclopedic treatise on how they determined time, how they broadcast time, what were the technological limitations, and what they thought was important. It also produced a synopsis of all those contributions which compared and contrasted the different methods, indicated what were the goals of the CCIR, and described why the CCIR recommendations were choosing particular methods already in use which were generally deemed to be best practices. The CCIR process that led to the 1970 Rec 460 produced nothing like those 1947 proceedings. That is the criminal difference between CCIR 1947 proceedings and recommendations for broadcast time signals and the 1970 recommendations. The process that gave us leap seconds was not merely based in fear, it was also based on maintaining ignorance. The closest thing to an admission that there might be reasons not to use UTC as specified by CCIR was Recommendation 485. That allowed for dates to be specified using either UTC or TAI, but ITU-R suppressed TF.485 in 1997, just before the push to remove leaps from UTC began. Based on all the history my impression is that it is not possible to obtain any official improvements in the documentation for the rules governing UTC nor for the way that authoritative information about leap seconds and DUT1 is disseminated. Any such improvements risk discussions that might delve into the origins and purpose of UTC. Fear means that ignorance must be maintained for the sake of hegemony. -- Steve Allen
Re: [LEAPSECS] Leap seconds have a larger context than POSIX
On Sun 2020-02-02T17:59:20+ Michael Deckers hath writ: > The maximum deviation |UTC - UT1| <= 0.9 s as stipulated in > 1974 by CCIR Rec. 460-1 has never been violated until now. That violates the agreement that the difference between UTC and UT1 would be encoded as part of the time broadcasts. > > In one case it was broken specifically because a high official at CCIR > > conceded to a high official from USSR and directed the BIH to violate > > the wording of the existing agreement. > > Do you mean the only violation of applicable CCIR rules, the > introduction of a leap second into UTC at 1973-01-01? Right. Sadler covers this in his memoir and in several contemporary publications. Delving into this reveals more of the fear in the process. Several memoirs show that the principals involved with the creation of UTC with leaps were very concerned that the change of broadcast time signals might cause havoc with ships using celestial navigation. Reading through those shows palpable relief when they managed to evoke from the Maritime Safety Committee of the IMCO a statement that Rec. 460 would not cause difficulties with navigation predicated on the expectation that governments whose radio broadcasts used new UTC would issue notices about the change of their broadcasts. That meant that the Time Lords did not have their arses on the line if a ships might collide as a result of the new system. With the maximum difference of 0.7 s that could be encoded in the radio broadcasts not being able to handle the 0.9 s difference that put their arses back on the line. Other concern was expressed that exceeding the 0.7 limit might be blamed on the BIH and might trigger governmental review of the operation and funding of the BIH. At that time about 80% of the funds for BIH were coming from Observatoire de Paris as slush from their allotment from the French government. That was hardly an "international" arrangement, but BIH had only just been handed the responsibility for maintaining TAI specifically because any other arrangement would have required effectively duplicating the expertise and hardware of the BIH and finding a way to fund that. Prompting governments or journalists to open an investigation into the process of writing an international "technical" specification that was violated in less than two years was not a welcome notion. -- 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] Leap seconds have a larger context than POSIX
On Sun 2020-02-02T00:33:08+0100 Warner Losh hath writ: > It's the fact that things like filesystems > specify an elapsed time since an epoch in a time scale without leap > seconds. Every FAT or NTFS disk around has a time like this. Beginning 2018-06-01 the value of Microsoft Windows FILETIME ceases to be seconds of UT since 1600 and begins to be (TAI - 37 s). Microsoft has decided to become the authoritative point of distribution for the leap second information that no international agency has ever been tasked to be. > Replacing steering systems > for telescopes is likely somewhat less than that. I have already written up how it is not an insurmountable problem for telescope systems, but digging deep into the literature from around 1970 even further invalidates any notion that leap seconds are for astronomers. In the many meetings and recommendations there were several instances where the participants and wording recognized the requests from astronomers to preserve UT. In every instance where a document specified a maximum deviation that agreement was later violated. In one case it was broken specifically because a high official at CCIR conceded to a high official from USSR and directed the BIH to violate the wording of the existing agreement. The leap seconds were included in the CCIR recommendation not because of anything any astronomer said, but because a few of the participants in the CCIR process understood that they did not have the legal authority to cause all nations to change calendar days from mean solar days to atomic days. -- 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] leap seconds in POSIX
On Sat 2020-02-01T00:01:22-0800 Hal Murray hath writ: > I was hoping that there would be a good white paper or blog that discussed all > the possibilities that have been considered and explained why they were > rejected. That cannot happen because of the other factor that has been in the politics of time since the 1950s: fear The surviving scientific and technical discussions indicate that two time scales were considered a plausible option. It was the regulatory context of the CCIR where two time scales were deemed unacceptable. The memoirs of the participants indicate that those discussions happened at conferences where the principals gathered but which were not actually part of the bodies who actually exercised authority. The discussions where the decisions were made are not recorded, and the discussion of those discussions at IAU 1970 was redacted. The fear comes from the fact that the broadcasts of time were funded by national governments. The urgency to adopt leap seconds came from the German law that which disenfranchised the German Hydrological Institute that had been providing old rubber second UTC and declared that only the PTB with its cesium seconds was able to provide legal time. If bureaucrats and lawmakers in other countries had access to documents which described the dichotomy between SI seconds and calendar days they might have legislated differently, and that would destroy decades of efforts to get all radio broadcast time signals to supply the same time scale. The fear seen in the redaction of the 1970 IAU proceedings is still clear early in 1972 just after the inception of leap seconds where G.M.R. Winkler of USNO (who was in charge of the 1970 IAU redaction) explicitly cautioned against open discussion of legal issues. By 1974 there had been enough recommendations and acceptance of UTC with leaps that Winkler openly remarked "The C.C.I.R. may have overstepped its remit in defining UTC" and then paraphrased Spock "The process that led to UTC may have been illogical, but it was effective." The problem for POSIX and any technical implementations follows from the carefully worded recommendations that were handed to bureaucrats to get their approval. The wording allowed the insiders to implement what they understood to be the only politically acceptable compromise. Anyone outside the process was thereafter condemned to conform to specifications for a political compromise that gave no clues about its underlying technical barrenness. -- 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] leap seconds in POSIX
On Mon 2020-01-27T21:17:54+ Tony Finch hath writ: > > The LOD effects are easier to see using the plots from the Paris > > bureau of IERS by requesting to remove the predictable tidal > > variations that basically look like noise on the second plot here. > > Do you have a link and/or instructions? I can't see how to get a chart > like that ... http://hpiers.obspm.fr/eop-pc/index.php?index=C04=en ask to remove tidal variations Be nice, this web server is not robust enough to handle everyone asking all at once. -- 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] leap seconds in POSIX
On Mon 2020-01-27T19:33:37+ Tony Finch hath writ: > It looks like we're in another long gap, based on the LOD chart and the > UT1-UTC prediction. The current gap is now the second longest... In the middle of last year the rotation of the earth accelerated enough that LOD went below 86400 for several weeks, and DeltaT decreased significantly. > https://datacenter.iers.org/singlePlot.php?plotname=FinalsDataIAU2000A-UT1-UTC-BULA=10 > > https://datacenter.iers.org/singlePlot.php?plotname=FinalsDataIAU2000A-LOD-BULA=10 The LOD effects are easier to see using the plots from the Paris bureau of IERS by requesting to remove the predictable tidal variations that basically look like noise on the second plot here. -- 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] leap seconds in POSIX
On Mon 2020-01-27T10:15:56-0500 Steve Summit hath writ: > Remarkably, though, *Microsoft* of all people seized the bull by > the horns and announced more-or-less proper leapsecond support in > Windows a little while back; it might be instructive to study > that effort for lessons. I think Microsoft was able to achieve this because Windows 10 is designed to be continuously updated, including leap second information, with new code from corporate headquarters. This would not have been possible with an earlier version of Windows, nor with most any other system. -- 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] IBM and negative leap seconds
This one is allowed to be funnier than the Rockwell Collins GPS receiver issue earlier this month. PH12911: CEELOCT FAILS TO RETURN A VALID TIME WHEN CVTLSO IS NEGATIVE. https://www-01.ibm.com/support/docview.wss?uid=isg1PH12911 In short: Strange time values are returned if an IBM system is configured with a negative number of leap seconds. Fix: Customer: Doctor it hurts when I do this. IBM: Then don't do that. -- 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] Fw: CGSIC Bulletin: June 2019 Public Document Review
On Thu 2019-06-13T20:36:04+ Richard Langley hath writ: > Relevant to our recent GPS leap-second discussion. IIRC all of the EOP values were not part of the original GPS messages, and we have no receiver (or telescope) that uses them. But these changes are no-brainer by saying that the estimates of parameters should be expressed in GPS time rather than UTC time. -- 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] aircraft GPS receivers hit by leap second bug
On Tue 2019-06-11T13:33:44-0700 Paul Hirose hath writ: > issued another letter to its user group, highlighting the exact problem: “We > found that a software design error resulted in the system misinterpreting > GPS time updates due to a ‘leap second’ event, which typically occurs once > every 2.5 years within the U.S. Government GPS satellite almanac update. Our > GPS-4000S-100 version software's timing calculations have reacted to this > leap second by not tracking satellites upon power-up and subsequently > failing. The U.S. Government distributed a regularly scheduled almanac > update with this ‘leap second’ on 0:00GMT, Sunday, June 9, 2019, and the > failures began to occur soon after.” This is obscuration throwing blame where it does not belong. Other models of GPS have had no problems. Better reporters have indicated that that the manufacturer issued a bad software update. -- 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] systematic offsets of BIH data tabulations
The issues of BIH Bulletin Horaire contain tabulations of clock offsets from the 1920s onward. Starting with 1931 Nicolas Stoyko had devised an algorithm for combining the contributions of all the observatories into a single "mean observatory". Issues of Bulletin Horaire tabulated Heure definitive as offsets of broadcast time signals and various observatories from the BIH mean. Unfortunately for posterity the mean observatory algorithm that was used into the 1960s produces a (potentially) different systematic offset for each calendar year. That means that simply picking up an issue of Bulletin Horaire does not allow its tabulations to be compared to any other year. One of the things that Nicolas and Anna Stoyko did just before they retired was to publish their best estimates for the systematic offsets of all BIH data starting in 1931. When those are plotted they look like the image on this web page. https://www.ucolick.org/~sla/leapsecs/BHsHn02p043.html -- 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] complete history of UT2
I have plowed through enough of Bulletin Horaire to find the complete history of UT2. https://www.ucolick.org/~sla/leapsecs/seasonal.html Missing from the earlier version of the plots on this web page was the story of how exactly the BIH performed the transition between the first version of UT2-UT1 and the second version. Naively the change of the expression requires a jump of 6 ms at the beginning of 1962, but that is not what the BIH dictated. Look at the middle plot and see how the year started along one curve and finished along the other. This also means that it is possible to make a complete regression of the values of TA-UT1 back to the inception of Essen's original cesium chronometer in 1955 July. Doing that requires modifying each of the varying forms of the tabulations in the pages of Bulletin Horaire so that everything is transformed into a single reference system. -- 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] Windows 10 time
On Mon 2019-04-15T12:46:15+0100 Tony Finch hath writ: > What are the actual requirements in the regulations? For the Euro markets https://www.emissions-euets.com/time-stamping-and-business-clocks-synchronisation max deviation of 100 microseconds or 1 millisecond or 1 second, granularity 1 microsecond or 1 millisecond or 1 second, depending on who you are and other latencies. During the development of these regulations drafts were calling for 1 microsecond. The above results came after closed-session powwows with folks from BIPM and other timing labs. -- 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] Windows 10 time
As noted previously, Microsoft has improved timekeeping in Windows 10 and as of 2018-06-01 FILETIME is now TAI - 37 seconds instead of UTC. Yesterday Dan Cuomo posted a blog entry https://techcommunity.microsoft.com/t5/Networking-Blog/How-NOT-to-test-the-Windows-Time-Service/ba-p/411592 which has explicit apologies for how bad time once was on Microsoft and refers back to a February post https://techcommunity.microsoft.com/t5/Networking-Blog/Top-10-Networking-Features-in-Windows-Server-2019-10-Accurate/ba-p/339739 which states that Microsoft will not smear (except, of course, when the system is configured to run the old way without leap seconds) with references to financial regulation agencies and Matsakis, Levine, Lombardi at ION last year. I am impressed that Microsoft has managed to go somewhere that POSIX still refuses to go. -- 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] DCF77 and the inception of leap seconds
On Sat 2019-02-02T18:32:25+ Michael Deckers hath writ: > The DCF77 service started on 1959-01-01 and sent astronomically > determined signals for UT2 or UTC until 1970-04-01 when the > signals of DHI stopped. The PTB used Cs clocks since 1962, > and the PTB time signals in DCF77 used steps but never used an > offset in rate. This is only partly consistent with what Bulletin Horaire shows. No surprise there. Folks remembering details the way they wish they were and not remembering other details is really common in the historical writeups about what time services did and did not do. -- 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] is leap smear legal in Germany?
The story about the German time broadcasts of DCF77 is in Bulletin Horaire. The story about the German decision that the old rubber second UTC form of coordination was not legal after CGPM adopted the cesium second is in the proceedings of the CCDS, and it is also indicated in several popular articles written by H.M. Smith. In his memoire about history of Greenwich D.H. Sadler told the story of a CCDS preparatory meeting where Andre Danjon was too sick, and the interim president was one of the cesium gang. Sadler wrote that the interim took a straw vote which turned out against cesium, then announced when the meeting would end so that folks could make travel arrangements home, then extended the meeting and took the final vote after some folks had left. The remaining votes came out in favor of cesium, Sadler objected to the CIPM, and the CIPM invalidated the vote and meeting and excluded both Sadler and the interim president from the next meeting. Sadler makes it clear that there were trolls among the time community in the 1960s. The Bulletin Horaire listings of two different parties in charge of DCF77 transmissions hint that there were similar tensions of purpose within Germany. The ITU-R library probably has reports from the CCIR working party meetings during 1968 and 1969 which would give more clues about the official stances of various nations. It would be interesting to dig further into the power struggle in Germany between the Hydrographic signals and the Metrological signals, and to see who and how it was argued that rubber seconds were no longer legal in Germany. This might reveal hints about whether the crisis in the CCIR that led to urgent creation of leap seconds was triggered by Gerhard Becker or someone else at PTB acting alone, or whether the cesium gang had talked through and decided that Germany was the expedient place to trigger the crisis. But now I am trolling and asking: Given that rubber seconds are illegal in Germany, is it legal to use Google/Amazon NTP servers that provide smeared leap seconds? -- 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] DCF77 and the inception of leap seconds
There is more history leading to the inception of leap seconds evident in close inspection of the issues of Bulletin Horaire. During the early 1960s the German federal time broadcast station DCF77 did not broadcast time signals 24 hours a day. Historically this was also true of many other time broadcasts which used equipment that was shared between many purposes. As the 20th century progressed many time signals were generally broadcast during those hours when the ionosphere was quiescent between transmitter and the expected set of navigational users. Ships near those transmitters knew to tune in and check their clocks at the right time. Furthermore, the signals from different places did not agree with each other, but they did agree with longitudes on local navigational charts. Different regions of the earth had assumed different local origins of longitude when making their charts, and those were not globally consistent with Greenwich at the fine level. Time was longitude, and longitude was time, and they had to agree. The local broadcasts used times offset from each other, but consistent with the charts in use. These broadcast time offsets persisted until new charts were issued and decreed to come into general use. I suspect that close inspection of regional navigational charts in the 1960s will show changes that are consistent with those of the time signals. In the early 1960s the DCF77 broadcasts were run by the German Hydrographic Institute for the sake of navigation. The time scale was not "coordinated". This continued several years after the various scientific bodies and CCIR Rec 374 said that everyone should be broadcasting the "coordinated" original form of rubber second UTC. About 1965 DCF77 changed its broadcasts such that there were two different kinds of broadcasts at different times of day. (Bulletin Horaire is not entirely clear on when; it had always been the case that BIH learned about a lot of changes after the fact.) The German Hydrographic Institute continued to control broadcasts at some times of day, and those were the CCIR-approved form of rubber second UTC. At other times of day the broadcasts were controlled from the German Metrology Institute (PTB). The PTB-controlled broadcasts were pure SI seconds thus making those broadcasts a form of Stepped Atomic Time which was approved as experimental by CCIR Rec 374-1 in 1966. Sometime after 1967 October when the CGPM approved the SI second based on cesium the German broadcasters convinced themselves that the rubber second form of UTC was no longer legal to broadcast in Germany. This departure from the agreed form of "coordination" led to the urgent series of CCIR working group meetings during 1968 and 1969 which resulted in the proposal for leap seconds presented to the CCIR assembly in 1970 February. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Mon 2019-01-21T15:32:27-0800 Paul Hirose hath writ: > On 2019-01-16 1:35, Steve Allen wrote: > > So starting 1970-01-01 DCF77 changed to broadcast Stepped Atomic Time > > (SAT) with second markers that were 1 SI second apart except on > > occasions when they were 1.2 SI seconds apart in order that the time > > markers would stay close to UT2. > I don't know when DCF77 inserted the step adjustments, so I created a small > table sufficient for an example. In Bulletin Horaire series J there are announcements of when and how big jumps should be inserted into SAT. I don't know what meeting prescribed that responsibility to them, but they did it. If the BIH continued to do this then when Germany shifted from old rubber UTC to SAT in 1970 they were almost certainly following the BIH jumps. Starting in 1967 BIH stopped Bulletin Horaire and started Circular D and their Annual Report. The BIH Circulars may be hard to find, but BIH Annual Report is in libraries. -- 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] the epoch of TAI, with no more doubt
On Mon 2019-01-21T22:00:16+ Michael Deckers hath writ: > [things that amount to wishful thinking that reality was simple] The pages of Bulletin Horaire reveal that time is nowhere near as simple as we would wish. https://www.ucolick.org/~sla/leapsecs/bhpages.html > Do you happen to know in which tabulation the jump by 1.6 ms > occurs? A3 minus which other time scale? The jump of 1.6 ms is clear in the tablulations of UT2 - A3 done by both Stoyko and Guinot, and both of them point it out. It was an inevitable side effect of changing from FK3 to FK4. It means that all reported values of UT2 from before 1962 must be adjusted if the desire is to have everything in a single homogeneous system. Stoyko and Guinot did not choose to do that. Curiously there is not a big jump in the value of UT2 - A3 at that same date which would have been caused by changing from the old expression for UT2 - UT1 to the new expression. I surmise that this means Stoyko and Guinot did correct the old values of UT2 for the change in that formula. But more surprising is an obvious change in the rate of both tabulations of UT2 - A3 at 1961-01-01. This leaves me wondering if the fix for the change of UT2 formula was done not by recomputing UT2-UT1 for all past values, but simply by subtracting the difference on that new years day. The answer to this deserves a close look at whether the slope difference matches the difference in the old and new UT2 expressions, and also a close look at the BIH annual reports to see whether they indicate the acquisition of computing machinery. -- 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] the epoch of TAI, with no more doubt
giving the timing of exactly when each signal was received, and then followup publications indicating how wrong each station clock was. Some of the discussions in Bulletin Horaire make references to changes made by observatories and transmitters, but most of the particular decisions and rationale made by the folks doing the broadcasting are lost to history. Transcribing and plotting Bulletin Horaire would allow for the reconstruction of a lot of when changes happened and good guesses at what the underlying strategy was. And, alas, reading through Bulletin Horaire also calls into question some content in the historical writeups. I will admit that it borders on insanity to actually read through Bulletin Horaire and pick out details. I suppose Guinot must have agreed, and I think that is why the precise records of earth rotation that the IERS inherited from the BIH begin at the transition from FK3 to FK4 on 1962-01-01. -- 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] the epoch of TAI, with no more doubt
On Sun 2019-01-20T15:15:54+ Michael Deckers hath writ: > On 2019-01-20 00:50, Steve Allen wrote: > > I took a closer read and cross reference of the relevant > > issues of Bulletin Horaire and finalized my web page. > > The epoch at which TAI was set is definitely 1961-01-01T20:00:00 UT2 > > Arias and Guinot say in "Coordinated Universal Time UTC: Historical > Background And Perspectives", online at > [https://syrte.obspm.fr/journees2004/PDF/Arias2.pdf]: > > "In 1961, the BIH assigned a common origin to these time scales > [atomic time A1 of USNO for other integrated atomic times] > by coincidence with UT2 on the 1st of January 1958 (Stoyko, 1961). > The same origin was used for the BIH mean atomic time." > > The reference is to: > "Stoyko A., 1961, Bulletin Horaire du BIH, Serie G, 241-245." > That is probably a source you may have access to. Those pages are a response to Recommendation 2 from the second CCDS meeting held 1961-04-11/1961-04-12. At the CCDS meeting BIH presented an initial effort to integrate and compare all the cesium standards for which data were available, and BIH was the only place with the timing data from all the labs. The BIPM has now scanned and published the proceedings from all the CCDS meetings, so anybody can look at this. During those CCDS proceedings is the discussion on what value to give to an atomic time scale: The president [Danjon] insists on the need to define a zero, even arbitrary, for the time scale; it is necessary to date terrestrial and astronomical events in a certain calendar. Guinot was working with BIH since 1952, so he must have been aware of Anna Stoyko's atomic time scale in 1961, and he may even have been one of the computers. > The quote implies that the BIH scale A3 (precursor of TAI) was taken > to agree with UT2 at J1958.0, but of course this does not rule out > that the two time scales also agreed at some later instant. The table with the inception of A9 in my web page from Bulletin Horaire ser 5 no 13 was created scant months after the original table in ser G no 8. The intro to the A9 table discusses the difference between the "5 anciens" standards and the 4 new ones. The intro explicitly states that the BIH is choosing to reset their value of all these atomic time scales at 1961-01-01T20:00:00 UT2. Guinot knew this, in part because after Anna Stoyko decided to create A3 and sync it with A9 Guinot later re-interpolated A3. More unquestionably, in Bulletin Horaire ser J no 1 p 3 Guinot wrote that the origin of A3 and all other BIH TAi values was 1961 Jan 1 and he referred to Bulletin Horaire ser 5 no 13. -- 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] tzdata and US gov shutdown
A blogger takes note of how the IANA timezone project has been working around the lack of new leap second information from US government sources. https://typesandtimes.net/2019/01/shutdown-warps-time -- 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] the epoch of TAI, with no more doubt
On Sat 2019-01-19T20:25:53-0500 Brooks Harris hath writ: > > https://www.ucolick.org/~sla/leapsecs/taiepoch.html > So when, how, and why did 1958-01-01 come in to it? I have further clarified the English, added more example calculations, and a postscript about two more quriky aspects of atomic time. -- 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] the epoch of TAI, with no more doubt
On Wed 2019-01-16T00:56:19-0800 Steve Allen hath writ: > The epoch of TAI, and LORAN, and GPS is 1961-01-01T20:00:00 UT2. > Or maybe 1961-01-00 UT2. I took a closer read and cross reference of the relevant issues of Bulletin Horaire and finalized my web page. The epoch at which TAI was set is definitely 1961-01-01T20:00:00 UT2 https://www.ucolick.org/~sla/leapsecs/taiepoch.html -- 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] Running on TAI
On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: > Hm, maybe that was originally the case. I wonder whether the folks who > wrote the text just had UTC in mind when they "invented" time_t. The best insight into the POSIX committee was posted on LEAPSECS in 2003 https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html Not clear in that posting was that Arthur David Olson's timezone code for Unix systems already contained the code written by Bradley White which allows time_t to count every second in the radio broadcast time scale and handle leap seconds. POSIX committee members knew that and decided to disregard it with words that actually prevented system designers from adopting a more correct scheme. > So IMO this clearly says that time_t has to be interpreted depending on > the context, and must not necessarily hold exclusively UTC numbers of > second. The tricky part comes when software on one system exchanges values of time_t with another system that believes time_t has a different value. > I think a good solution would be to have a structure that contains a > time_t value plus at least one flag that indicates the leap second > status, or a field with TAI index. It would be even better to have such > additional information available with struct timespec, so an application > can tell if the time stamp is inside a leap second, or not. I think that the entire infrastructure should recognize the notion of needing two kinds of time: precision seconds and civil days. That is what the astronomy community had understood and promoted since before 1950. That is the hard part. It is the part that technical folks punted on doing during the 1960s because it would have required explaining the need for two kinds of time to bureaucrats and legislators and waiting for them to change laws and regulations. Instead they chose to act quickly and implement something controversial and technically barren. The rest of the technical parts needed for the notion of two kinds of time have been discussed here before. The underlying time scale used for radio broadcasts and operations by any kind of machine should be purely atomic. The counting of calendar days and setting of civil clocks should be calculated using an offset from the underlying atomic time scale. The conversions from that underlying atomic time scale should be widely distributed by a robust scheme like the Domain Name System and financial transactions, and those conversions should not happen in critical places like the kernel but in other less-critical places like libraries for locale and internationalization. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Wed 2019-01-16T22:24:46-0800 Paul Hirose hath writ: > On 2019-01-16 1:35, Steve Allen wrote: > > > > Does it know that rubber seconds do not apply to timestamps in central > > Europe made using DCF77 from 1970-01-01 to 1972-01-01? > > All my DLL knows is what's in the UTC file. If the file indicates no rate > offset in the years 1970-71 and some fractional second step adjustments, > that's what you get. An existing file could be edited to match the DCF77 > flavor of UTC. Then construct a UtcTable object from the file: There lies the problem with timestamps, then and now. The folks running DCF77 had convinced themselves that German law did not permit them to broadcast seconds which were not SI seconds, so they stopped broadcasting the rubber second version of UTC which was then the CCIR standard. Instead they convinced themselves that broadcasting "mostly legal" SI seconds was more acceptable under German law. The issues of Bulletin Horaire over the decades show that the existence of any difference between the time signal broadcasts of any service was not acceptable and repeatedly resulted in internatioal meetings with recommendations putting pressure on every transmitter to conform. This was the reason for the creation of UT2. In the 1950s the issues of Bulletin Horaire show that the UK had started correcting their broadcasts, first for what would become called UT1, and then for what would be called UT2. The US Navy broadcasts did likewise, but using a different expression for what would become called UT2. The US NBS WWV broadcasts chose to prefer more steps and fewer frequency offsets than US Navy because the NBS was more interested in standard frequency than in astronomical time. Bulletin Horaire says that by 1955 there were at least 4 different schemes being used to produce broadcasts of time scales akin to what would become called UT2. Bulletin Horaire explains that was the motivation behind the 1955 IAU decision to create UT0, UT1, and UT2. Then folks became uncomfortable with the way that different stations attacked the problem of broadcasting something like UT2. The US Navy method of approximating UT2 using fewer time steps and more changes of frequency offset was good for navigators who would not see their position suddenly shift. The US Navy method was also an irritant, in part to folks who had been driving CCIR recommendations toward making better use of spectrum by reducing spacing between stations using adjacent frequencies, and in part to engineers who had to retune the transmitting gear. The existence of cesium frequency standards made it easy for everyone to see the changes in offsets that had previously been hard to measure, but it also allowed for the agreement on the original form of rubber second UTC where everyone agreed to use the same frequency offsets and time steps. The first version of that agreement was forged over tea in the living room of H.M. Smith, one of the Greenwich engineers associated with UK radio broadcast time signals over the span of his career. After the US and UK had codified their rubber second agreement it was taken to URSI, CCIR, and IAU to get official international status as recommendations. After the CGPM approved the cesium SI second, the German decision that in 1970 they would no longer conform to rubber second UTC led to urgent need to create yet another agreement on a different way of broadcasting time that could be legally tolerated in all countries. There was also dissatisfaction with the changes in frequency and time steps from the LORAN engineers who had to re-tune and re-phase entire chains of transmitters, and the LORAN users who could not navigate during the interval when the chain was retuning and rephasing. So for your software the German decision means that the only way to decode timestamps in central Europe from 1970/1972 is to find the publications where they announced when DCF77 inserted their markers which were spaced by 1.2 SI seconds. The USNO circulars which announced changes in their broadcasts were printed on high-acid paper which has self-destructed while sitting in the few libraries which bothered to store them. I do not even know the name of the German publications which would have announced their time signal steps. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Wed 2019-01-16T00:00:55-0800 Paul Hirose hath writ: > The "rubber second" era is supported. That accounted for about 90% of the > workload to create the UTC implementation! Does it know that rubber seconds do not apply to timestamps in central Europe made using DCF77 from 1970-01-01 to 1972-01-01? After the CGPM redefined the SI second in terms of cesium the German time service bureau determined that they could not use the old scheme of BIH UT2 with its rubber seconds. They had convinced themselves that German law required them to broadcast SI seconds. So starting 1970-01-01 DCF77 changed to broadcast Stepped Atomic Time (SAT) with second markers that were 1 SI second apart except on occasions when they were 1.2 SI seconds apart in order that the time markers would stay close to UT2. This was one of the issues of concern in the CCIR preparatory meetings that led to the decision to have leap seconds. So they were mostly broadcasting legal SI seconds, but too early in history to evoke comparisons with "mostly harmless" and "mostly dead". -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Wed 2019-01-16T09:03:26+ Poul-Henning Kamp hath writ: > In message <20190116085619.ga23...@ucolick.org>, Steve Allen writes: > >The epoch of TAI, and LORAN, and GPS is 1961-01-01T20:00:00 UT2. > >Or maybe 1961-01-00 UT2. > > > >That is when the atomic time scale was set to a specified value. > > But the specific value they set was not zero in 1961-01-01T20:00:00 UT2, > they set it so it would have been zero at 1958-01-01 00:00:00 GMT Because of the reset at 1961 (and other ingredients in the sausage of time) the difference between UT2 and TAI is not zero at 1958-01-01. It is close to zero, but it is not zero. One of the ingredients is that as of 1958-01-01 USNO was intentionally using a longitude that differed by 0.035 time seconds from the globally consistent value. I also have not read closely enough to say whether those offset values in the series H inception of A3 correspond to the values of UT2 before or after the longitudes of all stations changed on 1962-01-01. The global average for that shift was 1.5 ms. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Wed 2019-01-16T08:31:19+ Poul-Henning Kamp hath writ: > In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes: > >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 ? Nope. The epoch of TAI, and LORAN, and GPS is 1961-01-01T20:00:00 UT2. Or maybe 1961-01-00 UT2. That is when the atomic time scale was set to a specified value. See a few pieces of the way that sausage was made here https://www.ucolick.org/~sla/temporary/taiepoch/ -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T15:18:00-0800 jimlux hath writ: > 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) The 1970 CCIR decision to begin having leap seconds was made without any technical docuements about how to implement them. At a public meeting after the CCIR decision and prior to 1972 one of the delegates to the ongoing CCIR working group meetings was asked if he could talk about the details "unless that is sub judice". In the context that was a jab from someone who was not happy with the decision for leap seconds. But everyone was going to have to be using the new broadcast time scheme, so it was not funny then to be joking about technical details of the system being secret. That became even less funny over the decades. More disturbing were the contributions to the 1972 CCDS meeting where one of the technical delegates to the CCIR process wrote It is clear that the recommendation of the CCIR concering the UTC system is limited to "standard frequency and time-signal transmissions" in the sense of Study Group 7 of the CCIR. This recommendation does not concern other programs and other methods of broadcasting time, such as radio or television announcments of the hour, hourly services for maritime or air navigation, public clocks, etc. and Again, UTC is a way of providing AT and UT in the same broadcast. The CCIR feels responsible for transmitting AT and UT to users in a reliable fashion and with appropriate technical means. It does not matter to the CCIR that users employ AT, UT, or UTC for their particular problems. The responsibility of the CCIR ends with the transmission of UTC by the specified stations. Another delegate both to the CCIR and that CCDS meeting wrote We should limit ourselves to discussing this issue with people who are well aware of the problems involved. Those are basically the folks who made the CCIR decision saying Many folks don't have to use this, especially us. and Blame the victim if they don't use the right thing. and Let's not talk about this. So the result was that the technical folks did not talk about leap seconds. Nobody was ever tasked with setting up a scheme for transmitting information about leap seconds that was more automated and reliable than the BIH giving letters to the post office to send to various national time service agencies. But before the technical folks washed their hands they arranged for various international assemblies to produce statements approving of the leap seconds. Subsequently the bureaucratic folks took those statements to other national and international bodies and achieved approval for UTC with leap seconds in arenas where the original technical folks had admitted they might not be the best strategy. At this point in history it is unclear who of these technical folks believed that the CCIR decision had limited scope and who were being shrewdly tacit about their ongoing goals for international approval. The only internationally official clue that UTC might not be the best tool was CCIR recommendation 485 https://www.itu.int/rec/R-REC-TF.485-2-199006-W/en which allowed that TAI might be preferable to UTC for some purposes. This rec was withdrawn in 1997. That was just before the "leap seconds must die" process began in earnest in 1999. Ironically at the 14th CCTF meeting in 1999 the head of the BIPM opined that anyone who did not like leap seconds should use TAI as given in rec 485. This betrays that not even the head of BIPM, who define TAI, was aware that the ITU had withdrawn that rec two years earlier. As Captain said in Cool Hand Luke Whut we've got heyah is failya tuh c'municate. https://www.youtube.com/watch?v=V2f-MZ2HRHQ -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T10:50:10-0800 Tom Van Baak hath writ: > Nope. All minutes have 60 seconds in Excel. And in Windows. And > in Unix/POSIX. Really any computer system that uses a fixed "epoch" > and a ticking "counter" is ruined by leap seconds. The systems differ > in their epoch's, they all differ in their counters, they can all be > set to UTC, except they all fail when there's a positive or negative > leap second. Nowhere did the folks who were there at the inception of leap seconds say so explicitly, but from reading how things worked over the history of the time services and what the folks paid to provide those services wrote, I am reasonably sure that they also believed that all minutes consisted of 60 seconds, and all days consisted of 86400 seconds. I believe that the concept in their heads was that occasionally there are two calendar days which are not adjacent by one SI second. Or, if the earth rotation were to speed up enough, there might be two calendar days which overlap by one SI second. The notation 23:59:60 is merely a tag for conveniently indicating when a second was inserted between two calendar days. The clock is disconnected from the calendar. Understandably this notion should trigger objections that it is technically barren. At this point I would answer "Yes, and they knew that." They were being paid by their governments to provide the legal and operational time of their nations. Their job had always been to tell the people of their country how to set their clocks. So when a senator or cabinet official asked "Can you tell me what time it is?" they had learned over the course of their careers that the answer was not to wander off into a long technical discussion about how sausage was made, but to smile and say "Yes." Similarly for the 1970 CCIR decision about leap seconds: when facing a chamber full of folks at an international assembly that had the power to dictate how every member nation should set their clocks in the same way that was consistent with the laws of all those nations, the answer was to smile and say "Yes, everyone has agreed that this is the best way to do it." Their job was not to say that the technical folks who made that decision had already decided to disregard that in the systems that they controlled, broadcast navigational signals based on TAI, and make almanacs based on UT (not UTC). -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T13:10:54-0800 Gary E. Miller hath writ: > > What is the epoch that was used for TAI? > "TAI in this form was synchronised with Universal Time at the beginning > of 1958," That is conceptually the case, but even as a concept it deserves explanation about how it was that the USNO A.1 atomic time scale which was started with that same epoch differed from the BIH atomic time scale by 0.035 seconds. Furthermore, the epoch of A.1 was 1958-01-01T00:00:00 UT2 whereas the epoch of the BIH atomic time scale was 1958-01-01T20:00:00 UT2, but this does not explain the difference between the two time scales. That 1958 epoch is not the basis for the current incarnation of TAI. Tonight I will scan the pages of Bulletin Horaire with the answer. -- 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] leapseconds, converting between GPS time (week, second) and UTC
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? I expect that many can give an answer, and that nobody can give the correct answer. > The best bet is to ask the kernel for the current TAI time, and work > with that. Use the leap seconds file to convert TAI to UTC in your > code. Or just use TAI for everything. 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. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T11:49:00-0800 Tom Van Baak hath writ: > Still, I bet more astronomers use Python than Excel to point > telescopes. How do you handle the lack of leap second support in > Python? I can't say that anyone uses Python to point a telescope, but it does not matter if they do. See preprint 678 from the 2011 Future of UTC meeting proceedings http://hanksville.org/futureofutc/2011/preprints/index.html In short: 19th century telescopes point by moving them manually. 20th century telescopes are built like battleships and raw pointing is only a bit more accurate than steering a battleship. 21st century telescopes are robotic, but they still have flexure and slop that requires them to update their pointing models regularly, and those slop parameters easily soak up one second. The APF telescope at Lick is robotic. Its pointing system produces a time mismatch alarm whenever there is a leap second and requires a reboot. At the most recent summer leap second we were able to see a star before and after, and there was a jump in the centering. The software chose a different offset in the pointing for that night. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T12:52:18-0700 Warner Losh hath writ: > This suggests strongly that those models of time are fatally flawed and > should be revisited. I am probably the only person who has ever read all of Bulletin Horaire. https://www.ucolick.org/~sla/leapsecs/bhissues.html I can say that with certainty for the copies in the Lick library because I had to apply xacto knife to separate some of the pages which were not cut at the time of printing and never opened before I did. Over the lifetime of the BIH the staff were prone to be chatty and include transcriptions of the meetings which many times resulted in directions that the BIH must do more work in a different fashion. Those transcriptions point to the dramatis personae at those and other meetings, and to other documents. I can say unequivocally that the people who instituted leap seconds in radio broadcast time signals knew that the idea was fatally flawed. They also knew that they did not have the legal authority *not* to include leap seconds in the radio broadcast time signals, and they were not happy about the situation. They intentionally did not use UTC in their ongoing technical work. They intentionally avoided discussing the technical problems in public, redacted the transcripts of meetings that showed dissension, and arranged forced votes to produce statements indicating that various bodies agreed with the notion of leap seconds. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T12:41:27-0700 Rob Seaman hath writ: > 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. IEEE 1588 version 2 (PTP) makes it clear that the intended time scale on the underlying hardware is TAI counted from some epoch. It must be the case that vendors selling such hardware have chosen solution strategies and written code to handle converting between civil time and system time. I would love to find pointers to such strategies and code. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T11:40:07-0800 Tom Van Baak hath writ: > Also, presumably Python is based on POSIX? Does it use time_t or > gmtime? Why did Jim's quick Python experiment fail? Guido said that the mainline of Python would not support leap seconds. -- 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] leapseconds, converting between GPS time (week, second) and UTC
On Tue 2019-01-15T10:50:10-0800 Tom Van Baak hath writ: > Jim -- I'm replying via the LEAPSECS list because we love leap second > questions here. > > List -- Jim is a long-time member of time-nuts, works at JPL, and does > wonderful stuff. If you set your POSIX system clock at TAI minus 10 seconds then it keeps track of the number of seconds which have been counted in the internationally approved radio broadcast time scales. If you set your clock that way then you can use the "right" zones of the IANA tz distribution and get conversions between the internal system time and the civil time that has been specified in the international agreements. https://www.ucolick.org/~sla/leapsecs/right+gps.html Note that there are caveats to this scheme. -- 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] early efforts at uniform frequency
By the time of the 1950 meeting on Astronomical Constants held at Observatoire de Paris under the auspices of the CNRS the quartz clock engineers at Greenwich had some ocillators which were more stable than earth rotation. They still had a tendency for some of them to go rogue and stop being more stable, but with a large enough ensemble those could be identified and excluded. Using those quartz clocks made it possible to get a good measure of the seasonal variation of earth rotation. The BIH published the first expression for Delta T_S (what would become known as UT2-UT1) at the end of 1951. From 1952 through 1955 the UK radio broadcasts controlled by Greenwich were already applying that correction (as well as the UT1 correction they had started applying around 1947) to give a quasi-uniform time that they called Provisional Uniform Time (PUT). Before 1955 the USNO was also using such corrections in its radio broadcasts, and in 1955 their time scale was named N3c. The BIH published several subsequent expressions for the seasonal variation both before and after the IAU directed that all radio broadcasts should do that. The final version of UT2-UT1 was first used during 1962, by which point the time signal broadcasts were already regulated by cesium. Plots of the seasonal variation expressions are here https://www.ucolick.org/~sla/leapsecs/seasonal.html -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] more Windows 10 leap details
On Fri 2018-10-19T08:50:22-0400 Greg Hennessy hath writ: > Apparently the description of the mechanism is in the next blog > post. But this post does clarify that Microsoft has taken on the responsibility for distributing leap second announcements as part of the routine updates to the operating system. That is a big step forward for leap seconds. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] EMF Camp
-- Yesterday John Dalziel gave a leap second talk at EMF Camp https://www.emfcamp.org/line-up/2018/32-a-brief-history-of-leap-seconds the video stream is here https://mirrors.dotsrc.org/cdn.media.ccc.de/events/emf/2018/h264-hd/emf2018-32-eng-A_brief_history_of_Leap_Seconds_hd.mp4 -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the inception of leap seconds
On Wed 2018-08-15T12:49:14+0100 Zefram hath writ: > The announcement states a step size of 107600 us, but the expressions in > tai-utc.dat imply a step size of exactly 107758 us. The announcement is > ambiguous as to whether this step size is specified in microseconds of UTC > or of TAI, apparently ignoring the UTC frequency offset for this purpose, > though the offset isn't anywhere near big enough to account for the > discrepancy. The 107758 us computed from tai-utc.dat is in microseconds > of TAI, and the leap is only a few nanoseconds shorter in UTC. I did not scan the pages, but there are two issues which gave detailed tables of the values of the new time scale and the old time scale. IIRC the second issue declared that the first issue should be destroyed, but our librarian kept them both. I also did not scan many issues which gave the ex post facto corrections between the actual times broadcast by USNO transmitters and the times that they should have broadcast. I think that having to re-do the entire set of comparison tables is not surprising for the era when large amounts of manual effort were being expended to keep track of UT2 (which was still the time that CCIR and IAU had specified as the goal), the early form of coordinated time by the BIH that everyone was supposed to try to broadcast, and the atomic times. In the US both USNO and NBS were publishing their own tables of differences, as was the UK, and the BIH. I suppose some other harder-to-find agencies who had enough budget to do it might have similar volumes languishing at places where the librarians were conscientious enough to overrule the astronomers who knew nobody would ever look at them. But I tend not to scan those tables for my reference because the real story is in the accompanying brief notes about changes. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] no more listening to leap seconds?
This crossing over from time-nuts list, but it may mean that listening to leap seconds will become a thing of the past. If I understand this summary of the NIST budget request then radio stations WWV, and WWVH are set to be shut down. https://www.nist.gov/director/fy-2019-presidential-budget-request-summary/fundamental-measurement-quantum-science-and -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
On Mon 2018-07-23T13:18:22-0600 Warner Losh hath writ: > In the absence of setting a local time for the leap > second, the offset is controlling and therefore it happens at UTC midnight, > since it's definitely and unambiguously defined in ITU-R TF 460-6 as such > (all known earlier revisions too, I believe was the conclusion when a > similar issue was raised years ago on this list, though I think -3 was the > oldest that could be found at that time). We have managed to obtain scans of varying rattiness of all versions. More interesting than the versions themselves are the related recommendations (some since withdrawn) and the transcripts of the discussion in the voting sessions. Those give some clues into what had and had not been presented to the general assembly in order to motivate their approval of the new versions. E.g., from 1974 through 1997 the ITU-R recommeded using either UTC or TAI as appropriate. https://www.itu.int/rec/R-REC-TF.485/en CCIR Rec 460 had no details other than 1 second leaps. This original (version "0") Rec was reprinted in various places including by US NBS in Monograph 140, so it is online in scanned documents. The rules were worked out in CCIR Report 517 (Question 1/7, Resolution 53) by Study Group 7 during 1971-02-17/23. This put the leap second at UTC midnight. It is also reprinted in NBS Monograph 140. This was incorporated into Rec 460-1 by the CCIR general assembly between 1971-02-17/23 and remains the same in all subsequent revisions. CCIR and ITU-R documents mention UTC, UT[012], and TAI, and they refer the reader to other agencies for definitions of those terms. They do not mention local civil time, -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
On Mon 2018-07-23T13:58:49-0400 Stephen Scott hath writ: > I have not found any specifications or official documents that specify that > the leap second shall be incorporated just before the time instant midnight > UTC for all UTC offset timescales. There is no authority for "all UTC offset timescales." All local times are decided by local jurisdictions. This is an issue long treated in the IANA tz mail list which is a community effort that makes best effort to track every little change made by every legislature and bureaucrat. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
On Fri 2018-07-20T12:16:07-0600 Warner Losh hath writ: > Unless you are at UTC+0, I don't see how this can be right... Leap seconds > happen during the day for most time zones... On Fri 2018-07-20T16:11:12-0400 Stephen Scott hath writ: > What I am asking is WHY. > Where is the standard for that? > Or at least some document that specifies that? On Mon 2018-07-23T14:05:13+0100 Tony Finch hath writ: > The standard for leap seconds is ITU-R TF.460 > > https://www.itu.int/rec/R-REC-TF.460/en Most legislation and decrees about legal time specifies that the local civil time is some number of hours and minutes different from GMT or UTC. Taking the simplest interpretation on January 1 on every other day 23:59:59 UTC is 15:59:59 PST on every other day 00:00:00 UTC is 16:00:00 PST so most simply 23:59:60 UTC is 15:59:60 PST If the base time in the law or decree is GMT (as it was in the US until 2007) then all of this is by convention following whatever official metrology agency is tasked with providing legal time for that jurisdiction. A law could specify what Microsoft reportedly did in Azure, that is, Kiribati could apply the leap at the begin of their January 1 13 hours before of 0h UTC, and Hawaii could apply the leap 11 hours after 0h UTC, but it is hard to imagine legislators and bureaucrats getting that specific unless their metrology agencies provided powerful technical arguments about why being off by one second for all of those hours was less harmful than taking the leap second in the middle of the day. That might happen if some international regulatory or scientific agency produced a recommendation saying that every nation should do leap seconds at local midnight, but that just moves the "hard to imagine" into a different arena. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
trust, and reduced usefulness because some folks wanted to take what looked like a politically expedient shortcut which was full of unexplained technical complexities. It is not clear who can remedy things. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
On Thu 2018-07-19T04:14:12+0100 Stephen Colebourne hath writ: > "In addition, there is no standard method for applying this frequency > adjustment, so that different implementations may disagree among > themselves in addition to the time error with respect to UTC." That quote is not from Microsoft, but rather from the ION paper by Matsakis, Levine, and Lombardi That can be got by ION members, or from USNO if their webserver recovers, or from researchgate if you can tolerate the javascript that will try to execute https://www.researchgate.net/publication/323600621_Metrological_and_legal_traceability_of_time_signals Microsoft seems to be documenting a new mode of OS configuration which actually does count the second named "60", and specifically in order that Microsoft systems can say they conform to MiFID II and other regulatory agencies that demand conformance with UTC as defined. Otherwise the old default configuration will have a second that lasts 2000 millis. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Windows Server 2019
as seen on slashdot and more, Windows Server 2019 will support leap seconds. https://blogs.technet.microsoft.com/networking/2018/07/18/top10-ws2019-hatime/ That blog entry points at several MSword docs for admins and devs, and https://aka.ms/Dev-LeapSecond finishes with this interesting warning: Known issues: Some frameworks are known to calculate time incorrectly after a leap second occurs. For example, the .NET Framework uses its own internal logic to determine what time it is. Its logic does not account for leap seconds. So after a leap second is introduced to the Operating System the output of "System.DateTime.Now.ToString()" will be ahead by one second of the local system time. (We are working with the .NET framework team on this.) In combination with the many steps that it takes to configure Windows this sounds like there will be some really interesting results. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] anybody watching the NTP pool?
It will be interesting to see how many systems try to implement a leap second at the end of this week. Sites with broken leapseconds files are invisible beforehand, but stuck NTP leap bits may be showing up already. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] the inception of leap seconds
Back in March Demetrios Matsakis objected to some of my web pages and also pointed out the role that Gernot Winkler had in their inception. That led me to dive deeper into the Lick Observatory Library and find more documents which present contemporary views of the people who were there at the inception. Among many things I have found is a paraphrase of Arthur C. Clarke in Childhood's End Leap Seconds are not for Navigation https://www.ucolick.org/~sla/leapsecs/leapincept.html Even deeper in the libary are other documents which shed light on things that went wrong before the inception of the earlier form of coordinated time in radio broadcasts. -- 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] UT1 via NTP
On Wed 2018-03-21T08:51:37-0700 Steve Allen hath writ: > Our robotic telescope with small FOV on the guider does better if it > is given UT1 to 0.1 second. That telescope grabs the USNO predictions > of EOP every week to update the pointing. I'll add that I do not see any place where I would want to use UT1 via NTP for astronomical observations. The real-time operation of the telescopes does not want to be dependent on a very small number of external real-time sources over telecomm links that can fail. That is why we rely on the USNO predictions, for they give us several months of lookahead. Thus also we have several months of warning if the USNO decides to stop publishing EOP, and that is enough time to engineer a replacement source of information. It was not happy when DoD was doing theater-level jamming near Hawaii and the Keck telescope GPS time servers had dates that were completely insane. In that case the local system clocks retained sanity for the duration of the jamming. In extension of all this I argue again that what is really wanted is a source of Atomic Time that is completely robust plus a widely disseminated source of tabular or polynomial predictions of Atomic Time minus Universal Time. -- Steve Allen<s...@ucolick.org> 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] UT1 via NTP
On Wed 2018-03-21T03:19:15-0700 Hal Murray hath writ: > I haven't seen any comments from astronomers with info on how accurate they > need UT1. It depends. I described several telescopes for Future of UTC. paper 678 at http://hanksville.org/futureofutc/2011/preprints/index.html Optical telescopes have to be able to find a target where atmospheric refraction amounts to several arc minutes, and unpredictable variations of that can amount to many arc seconds. So in many cases one second of time is plenty good. Our robotic telescope with small FOV on the guider does better if it is given UT1 to 0.1 second. That telescope grabs the USNO predictions of EOP every week to update the pointing. -- Steve Allen<s...@ucolick.org> 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [Non-DoD Source] D.H. Sadler in 1954
.iop.org/article/10.1088/0026-1394/8/3/004 in the last few years regrettable misunderstandings, especially between astronomers and physicists, have crept into discussions on time and frequency in a way that seems like sorry, not sorry. bottom of p.195 has another break in the flow where Winkler reported that the IAU had received no official communication from the CCIR about the leap second even though a CCIR resolution had stated the IAU should be informed. H.M.Smith said that in the absence of official word CCIR to IAU there could be no comments from Comm 31. Smith then mentions 6 points raised in an earlier meeting. That seems like it fits the break in the flow on p.194. Winkler then stopped discussion about the CCIR and allowed "free discussion" which is not recorded. -- Steve Allen<s...@ucolick.org> 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] D.H. Sadler in 1954
In 1954 D.H. Sadler produced a monograph on the changes in time that had been resolved at the 1952 IAU General Assembly. His writeup is clearer than almost anything else for the next 60 years. It was published in Occasional Notices of the RAS, and it has been hard to find until now. https://www.ucolick.org/~sla/leapsecs/twokindsoftime.html This is one of the series of documents produced starting in 1948 and proceeding through the next 20 years where astronomers explained that two kinds of time would be needed to satisfy all applications. -- Steve Allen<s...@ucolick.org> 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] the first TAI
I have been diving through the library volumes with the contemporary records of the early days of atomic chronometers. One of the things that stands out is in this image https://www.ucolick.org/~sla/temporary/tai1960.jpg Temps Atomique Intégré was first published in Bulletin Horaire, Series G, Number 8 (1960 Mar/Apr) Note that while this issue contained the tables of Heure Définitive for 1960, it refers to a CCDS meeting that happened 1961 April 11/12. At this epoch the slower issues of BH with the final values of time were being published more than 12 months after the dates they tabulated. Even the faster issues of BH with the semi-final values of time were being published about 10 months after the dates they tabulated. Worse, the issues which contained the predicted corrections for transforming raw UT0 meridian observations into the values of UT2 required for broadcast time signals were being published after the dates those corrections were needed. There can be little doubt that these large delays of the perennially under-funded BIH prompted URSI and IAU to recommend the use of coordinated frequency offsets and time steps rather than the old way where every observatory used its own observations to produce the reference clock for its own radio broadcasts. But I digress from this first publication of TAI. I have not seen any historical synopsis that mentions this first use of a time scale with the initials TAI. Has anyone seen a reference to this use? If not, that begs the question of why not? -- Steve Allen<s...@ucolick.org> 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] leap seconds since WRC-15
At the 2015 WRC the general assembly seemed to admit that the folks pushing to abandon leap seconds had not done their homework. In the interim the news has been thin, but there are some good clues that the homework is being done. The clearest of all these comes directly from the BIPM itself and gives a timeline of many things that have been happening and will be happening https://www.bipm.org/cc/PARTNERS/Allowed/2016_October/5-Decision-of-the-WRC-2015-on-the-leap-second.pdf Folks who are editing the wikipedia page on the leap second process may wish to review this as citable evidence of what is happening. This lays out that the BIPM watched the CCTF create a task group under the Working Group on TAI (WGTAI). The Task Group on Time Scale Definitions (TGTSD) first met 2016-09-28. Much, more, this lays out the timeline as seen from the BIPM. The TGTSD submitted a report to the CCTF meeting 2017-06-08/09. That approved a recommendation sent to the CIPM 2017-10/11 which might have approved a recommendation to be sent to CGPM 2018. The timeline continues into the future with a description about what the CGPM might be asked to do includes the words "after the revocation of Res. ITU-R TF. 460-6". The membership of TGTSD is visible in https://www.bipm.org/utils/common/pdf/DIR/DIR2016/time2016.pdf Also, in late October ITU-R WP7A met in Geneva. The title of a result from that meeting is visible as [43] Annex 02 - Working document towards preliminary draft new Report ITU-R TF.[UTC] - Content and structure of time signals to be disseminated by radiocommunication systems and various aspects of current and potential future reference time scales, including their impacts and applications in radiocommunication and WP7A also sent Liaison statement to Working Parties 4A, 4B, 4C, 5A, 5B, 5C, 5D, 6A, 6B, 6C, 7B, 7C and 7D which can be supposed as an alert that they all might want to read the working document. It is too soon for detailed clues about what just happened at CIPM and WP7A, but things are clearly moving along. -- Steve Allen<s...@ucolick.org> 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 http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
