Re: [LEAPSECS] Fwd: IERS Message No. 354: Recent changes to the IERS 14 C04 series / Bulletin B
On 2018-05-07 12:41, Rob Seaman wrote: Anybody have more details about this? How it happened or what it might mean for practical timekeeping? Rob -- Forwarded Message Subject: IERS Message No. 354: Recent changes to the IERS 14 C04 series / Bulletin B Date: Mon, 7 May 2018 10:57:14 +0200 (CEST) From: central_bur...@iers.org To: messa...@iers.org IERS Message No. 354May 07, 2018 Recent changes to the IERS 14 C04 series / Bulletin B Dear IERS users, From its production in February 2017, 14 C04 nutation was only based upon the IVS combined solution according to a recommendation issued by representatives of IVS and IERS. But, on March 3, 2018 it turned out that IVS combined solution had not been updated since January 13, when Bulletin B was made. So, celestial pole offsets (CPO) were set to zero after this date. In order to fix this problem, on March 3 we run again the C04 combination by taking all VLBI solutions, of which the last UT1/CPO determination went back to February 12. So we had to update the C04 series from January 13. With this new solution, the pole coordinates and UT1-UTC were slightly changed. There was a also a serious flaw in UT1 values till January 2018, where UT1 intensive values are no more accounted after we wrongly follow an advise of an IVS/IERS representative. Because of the error interpolation, UT1 solution was seriously downgraded between IVS dates. Whereas the precision of UT1 intensive is about 30 micros (against 10 micros for R1/R4 UT1), the error introduced by interpolation between two IVS dates is probably much larger. We came to this conclusion, after Frank Reinquin (CNES) put forward an anomalous increase of SLR LAGEOS 1/2 orbital residuals using the 14 C04. Then we discovered that these anomalies were precisely located at the dates where UT1 intensive had been ignored, and replaced by a pure interpolated values between neighbouring R1/R4 sessions. According to the decision of the IERS Directing Board of April 8, 2018 the 14 C04 solution for UT1 was modified on April 16, 2018 by including the contribution of UT1 intensive back to 1996. The old version, updated until 2018/04/16 was put in the directory ftp://hpiers.obspm.fr/iers/eop/eopc04/eopc04.2017/. I am just guessing what is meant. Here is my tentative de-Frenchification: [From its production in|Since] February 2017, [|the] 14 C04 nutation [|data for the deviation of the observed celestial intermediate pole CIP from the pole of the 2006 nutation series] was [only based upon|derived only from] the IVS combined solution [|for the CIP,] [according to|following] a recommendation issued by representatives of IVS and IERS. [But,|Also,] on March 3, 2018 when Bulletin B [|for 2018 February] was made it [turned out|was discovered] that [|the] IVS combined solution had not been [updated since|kept up to date after] January 13. So, celestial pole offsets (CPO) were [set to|determined to be] zero after this date [|2018-02-13]. In order to fix this problem, on March 3 we [run|ran] again the C04 combination by taking all VLBI solutions, of which the last UT1/CPO determination went back to February 12. So we had to update the C04 series from January 13 [|onwards]. With this new solution, the pole coordinates and UT1-UTC were slightly changed. There [was a also|also has occurred] a serious flaw in UT1 values [till|before] January 2018, where UT1 [intensive values|values derived from intensive VLBS observations] [are no more accounted|were no longer taken into account] after we wrongly follow[|ed] an [advise|advice] of an IVS/IERS representative. Because of [the error|this erroneous] interpolation, [|the] UT1 solution was seriously [downgraded|degraded in] between IVS dates. Whereas the [precision|uncertainty] of UT1 [intensive|data taken from intensive VLBR observations] is about 30 micros[|econsds] ([against|as opposed to] 10 micros[|econds] for R1/R4 UT1), the error introduced by interpolation between two IVS dates is probably much larger. We came to this conclusion, after Frank Reinquin (CNES) put forward [|evidence of] an anomalous increase of SLR LAGEOS 1/2 orbital residuals [using|with respect to] the 14 C04 [series]. Then we discovered that these anomalies were precisely located at the dates where UT1 intensive[|s] had been ignored, and [|had been] replaced by [a pure interpolated|] values
Re: [LEAPSECS] [Non-DoD Source] D.H. Sadler in 1954
On 2018-03-17 23:34, Brooks Harris wrote: DocTranslator did a nice (free) job of translating this pdf to English - A) Download to your local drive B) Drag to DocTranslator C) Double check the source language - it didn't detect the French D) It will ask you to save the result to your local drive DocTranslator https://www.onlinedoctranslator.com/ Thanks for the hint! Actually, I should have mentioned that the document [https://www.bipm.org/utils/en/pdf/CGPM/Convocation-2018.pdf] contains the English version after the French text, so there is no need to use an automated translator to English. And the BIPM always stress the fact that the French version is the definitive one, parbleu. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the first TAI
On 2018-02-05 08:11, Steve Allen wrote: 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 Great find! ...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? I have seen "temps atomique integré" in [Audoin 1998, p 53..55], where the authors explain it in detail, and say that it was used from 1960 until 1969-01-01 as a local atomic time scale at the BIH. Their point is that comparisons of the readings of distant atomic clocks (first done via VLF time signals) did provide good accuracy for the frequency but insufficient accuracy for the phase (even if done every so often). Hence the BIH was forced to integrate (over a time scale apparently determined with quartz clocks!) a mean value from atomic frequency observations to obtain a consistent time scale with the rate determined by Markowitz et al. The advent of LORAN-C reduced the uncertainty of long distance comparisons to the 1 µs level and the BIH then formed a mean reading of atomic clocks (modern TAI, or, rather, EAL) -- as opposed to the integral of a mean of the observed rates of these clocks (integrated atomic time). The name, TAI, is used (proleptically) to denote both scales, and more, since 1955. HTH Michael Deckers. [Audoin 1998] Claude Adoin, Bernard Guinot: "Les fondements de la mesure du temps. Comment les fréquences atomiques règlent le monde". Masson. 1998 Paris. ISBN 2-225-83261-7. There seems to be an English translation for those who have not perused scores of volumes of the BIH. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap seconds since WRC-15
On 2017-11-26 23:29, Steve Allen wrote: 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. Thanks for the info! While the ITU actions are difficult to follow by outsiders, BIPM actions are more easily visible. I find it most relevant that the BIPM seems to intend to make leap seconds a topic in the next CGPM in 2018-11. See http://www.bipm.org/cc/PARTNERS/Allowed /2017_October/Plans-for-the-26th-CGPM-M-MILTON.pdf The CGPM is similarly influential as the WRC on the international level, they have have ties with the OIML, and they are probably more metrology-oriented than the ITU. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] first use of the terms UT0, UT1, and UT2
On 2017-10-14 22:57, Steve Allen wrote: Documents about the origin of the terms UT0, UT1 and UT2 have not been widely available. In the issues of Bulletin Horaire from the BIH in 1955 I have found a detailed synopsis of the IAU GA which decided that the measurement of time should change in that fashion, and also what I believe is the first published use of those terms. http://www.ucolick.org/~sla/leapsecs/BH1955.html These show the tensions between astronomers, physicists, and radio engineers. They provide insight into the level of understanding of various participants and the goals they were seeking. They also hint at the incredulity of Nicolas Stoyko of the BIH as he got the answer to his question "You want it when?", because the IAU resolutions from 1955 required changes by every observatory, every radio broadcast of time signals, changes to all the computations at the BIH, and a whole new level of rapid coordination between the International Latitude Service and the BIH. Thank you for these interesting primary sources! They corroborate (or at least they are consistent with) the following secondary sources: ∙ Felicitas Arias and Barry Guinot who write: "The distinction UT0/UT1/UT2 was introduced in January 1956. At the BIH, UT was an average of the UT0’s of the participating observatories." in "Coordinated Universal Time UTC: Historical Background And Perspectives". online at [syrte.obspm.fr/journees2004/PDF/Arias2.pdf] ∙ D H Sadler in "Mean Solar Time on the Meridian of Greenwich" in Quarterly Journal of the Royal Astronomical Society vol 19 p 290..309. 1978, online at [http://articles.adsabs.harvard.edu/cgi-bin/article_queryform ?bibcode=1978QJRAS..19..290S] who writes: "As a result of informal discussions between BIH and the former (H Spencer Jones) and current (Wm Markowitz) Presidents of [IAU] Commission 31 [on Time], the following terminology was adopted and used from 1956 January 1: UT0 is Universal Time as formerly computed; UT1 is UT0 corrected for observed polar motion; UT2 is UT0 corrected for observed polar motion and for extrapolated seasonal variation in the speed of rotation of the Earth The adoption of this terminology was reported to Commission 31 at the 1958 (Moscow) General Assembly [30: Trans IAU X, 489. 1960], but (although generally accepted) it appears never to have received formal approval by the IAU; it was not reported to Commission 4 [Ephemerides], and was clearly intended for specialist use in the time services." ∙ the bio of William Markowitz in [http://ad.usno.navy.mil/wds/history/markowitz.html] who says "At the International Astronomical Union (IAU) meeting in Dublin in 1955 he proposed the system of UT0, UT1 and UT2 which went into effect within months and remains today." except that, nowadays, UT0 is useless because local sidereal time is a derived rather than an observed quantity, and UT2 is rarely used. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-31 14:13, Tony Finch wrote: Y'know, if you are going to argue with one of my messages, it would be more polite not to snip the sentence I wrote which agrees with your points. You wrote a good pedantic analysis of the problem; a pity it wasn't also kind. I am sorry I was impolite; I did not intend to. Nor did I intend to argue with your message (but only with the text of IERS Bulletins C). I try to snip all text that I find unnecessary for understanding the point I am going to make; unfortunately, I had snipped too much. And thanks for your response. Michael Deckers. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-02-01 05:10, Brooks Harris replied to my scribbling: Actually, there is just one official document defining UTC (ITU-R Rec 460); plus of course the Bulletins C of the IERS. Generally I agree these are the two most relevant documents. But Rec 460 doesn't point you to Bulletin C specifically, IERS has many other products, and the BIPM Annual Report on Time Activities looks official, and it is. Its scattered in the sense you can't find anything, or, rather, you find many things, and Rec 460 doesn't say "as per IERS Bulletin C". Only after much research might you conclude Bulletin C is the most official, or most important, or most punctual, of the IERS products. Even now I'm not completely sure of that, that there isn't some other document somewhere Sure, there are many statements about UTC by other standardization bodies (BIPM, IERS ISO,..). And it can certainly be interesting to know what they all have to say. Both IERS Bulletins C and D (about DUT1) concern ITU-R Rec 460. But I doubt they can say anything authoritatively about UTC that is not in ITU-R Rec 460. They may well be wrong about it: the ISO C standard once allowed for leap second jumps of 2 s, and the current ISO SQL standard still allows for it. The BIPM made an effort to get the authority about UTC (after all, they already have it for TAI) but the ITU declined. Michael Deckers. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-30 21:39, Tom Van Baak wrote:
2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
I do have problems with your notation.
You apparently want to say that
"whenever TAI assumes the value 2017-01-01T00:00:35.5,
then UTC assumes the value 2016-12-31T23:59:59.5"
but I do not see which two things are denoted by the two
members of your equation, and are supposed to be equal.
If the value of the left member is the set
{ X : TAI( X ) = 2017-01-01T00:00:35.5 }
of all points X in spacetime where TAI assumes the value
2017-01-01T00:00:35.5, and similarly for the right member,
then in fact you would have a correct equation.
But the notation
2017-01-01T00:00:35.5 TAI
normally is not taken to mean a set of points in
spacetime, but the epoch 2017-01-01T00:00:35.5
with the additional information that it is a value of
the TAI time scale.
2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
I am completely lost here. If your first equation was
A = B, then you are now saying A - 36 s = B. I cannot
make sense out of it.
If you mean
2017-01-01T00:00:35.5 - 36 s = 2016-12-31T23:59:59.5
then why not say it?
My original point was that your arithmetic on datetimes
was confused. If the additive group of time values operates
on datetimes in the usual manner, then
2017-01-01T00:00:00.5
= 2017-01-01T00:00:00.5 + 0 s
= 2017-01-01T00:00:00.5 + (36 s - 36 s)
= (2017-01-01T00:00:00.5 + 36 s) - 36 s
= 2017-01-01T00:00:36.5 - 36 s
= "2016-12-31T23:59:60.5" in your notation
as I claimed. But possibly you do not want to use
the usual operation of the group of time values on
datetimes. I cannot reasonably comment on your posts
it unless you specify rigorously which operations
you mean.
Michael Deckers.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-30 21:36, Brooks Harris wrote: It seems to me this is where the UTC specifications are scattered over many documents and no one document makes it clear by itself, and this leaves room for misunderstanding. Actually, there is just one official document defining UTC (ITU-R Rec 460); plus of course the Bulletins C of the IERS. Everything else is interpretation and not necessarily correct. So I do not see a problem with scattered documents. What is missing quite a bit, as far as I can see, is a set of commonly accepted and applied "mises en pratique" for the leap seconds of UTC: documents that provide guidance for dealing with leap seconds in specific areas. Michael Deckers. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-30 19:21, Tom Van Baak wrote: 2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5 What kind of arithmetic is that? 2017-01-01T00:00:37.5 - 37 s = 2016-12-31T00:00:00.5 The question was whether 2017-01-01T00:00:36.5 - 37 s is < 2017-01-01 or >= 2017-01-01. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-30 13:06, Tony Finch wrote: It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC changes: from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC : UTC-TAI = - 36s from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s Pretty clear? Let's try. What does Bulletin C52 say about the relationship between UTC and TAI when TAI is equal to 2017-01-01T00:00:36.5. Obviously, UTC - TAI at that instant must be either -36 s or -37 s. • If it is -36 s, then UTC = TAI + (UTC - TAI) = 2017-01-01T00:00:36.5 - 36 s = 2017-01-01T00:00:00.5. This is > 2017-01-01, so by Bulletin C52, UTC - TAI = -37 s, contradiction. • If it is -37 s, then UTC = TAI + (UTC - TAI) = 2017-01-01T00:00:36.5 - 37 s = 2016-12-31T23:59:59.5. This is < 2017-01-01, so by Bulletin C52, UTC - TAI = -36 s, contradiction. Fact is, the statement of Bulletin C52 cannot be true when the value of TAI is during a positive leap second, but it doesn't say so. So yes, pretty tricky. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-29 16:18, John Sauter wrote:
Based on the definition of UTC, it seems to me that there are two
cases, both of which are very simple. For a negative leap second, the
change in TAI - UTC happens instantly at UTC midnight, which is one
second after 23:59:58, when the difference changes by -1. For a
positive leap second, the change happens gradually over the time of the
leap second, from 23:59:60 to midnight, when the difference slowly
changes by +1.
No, the difference TAI - UTC cannot change "slowly" because
it always must be an integral number of seconds. ITU-R TF.460-6
says
"It [UTC] corresponds exactly in rate with TAI but differs
from it by an integer number of seconds."
Changing the difference "slowly" in the sense of differentiable
would also cause a deviation in rate between TAI and UTC.
This sounds like an interesting story--can you provide more details, or
a reference? I was able to learn only the basic facts:
http://www.bipm.org/metrology/ionizing-radiation/units.html
The SI deviates from two of their principles with the
introduction of the unit Sv: having at most one derived
SI unit per dimension ("kind of quantity"), and not using
the unit to specify the quantity. The excuses are in the
"Considering" sections of CGPM 16 1979, Resolution 5 and
CIPM Recommendation 1 of 1984, as reprinted in the SI Brochure
[http://www.bipm.org/utils/common/pdf/si_brochure_8.pdf].
Michael Deckers.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-29 04:48, John Sauter writes about labeling a positive leap second 59 as done by Felicitas Arias: She prefers to label the leap second as a second 23:59:59, but the UTC definition calls it 23:59:60. Yes, of course -- I did not want to dispute that. My point was that Arias' labeling makes it clear that the latest discontinuity in TAI - UTC occurred when TAI assumed the value 2017-01-01 + 36 s. The ITU labeling (nor any other specification in ITU-T TF.460-6) does not imply the precise instant of the discontinuity, nor does IERS Bulletin C52. And about the "danger" of leap seconds through computer failures, John Sauter writes: I would not blame leap seconds but the programmer who did not properly test for leap seconds when developing his software. Leap seconds have been around for over 30 years, so it isn't like they are a new requirement. Of course you are right -- leap seconds cannot be blamed for computer failures, but careless programmers and inconsistent or incomplete program specifications may well be. But my point was not who or what was to blame -- I rather wanted to indicate circumstances where even the slowest bureaucracy can react swiftly in a very pragmatic manner: if the presence of leap seconds might cause harm to human health then their abolition is likely. See the introduction of the unit Sv as a special name for Gy by the BIPM as an example. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC radio Crowd Science
On 2017-01-28 17:33, Steve Allen wrote: BBC radio Crowd Science took a listener question about What is the Real Time? and produced a half hour tour that included three atomic Time Lords Whibberley, Matsakis, and Arias. http://www.bbc.co.uk/programmes/p04q778b and concluded pretty much saying that we have a choice. Thanks for that link! I find it remarkable that Arias in effect stated that the discontinuities of the difference TAI - UTC happen at the beginning of leap seconds, so that positive leap seconds are labeled as the second 59th seconds of a minute. Neither the ITU definition of UTC nor the IERS bulletins about leap seconds specify that detail, unfortunately. She is also stated to call leap seconds a "dangerous thing" -- as soon as this is substantiated (such as by a loss of health connected with a computer misinterpretation of leap seconds) it will be a powerful argument for their abolition. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken
On 2017-01-04 09:03, Martin Burnicki wrote: I think this you statement isn't quite fair. If a web server delivered a page with broken HTML code you wouldn't blame the web server daemon, e.g. apache, would you? It's the task of the web server admin to configure the server correctly and make sure the original PHP or HTML code is such that the delivered page isn't broken. IMO this is similar to ntpd. If it's not provided with an updated leap second file then it may have no idea that a leap second is approaching. If a faulty GPS receiver passes a leap second warning to ntpd, should ntpd not trust the GPS receiver since it knows there are some broken receivers out there? Well, a warning is not even a promise, and promises may be broken. This leads me to the question which has puzzled me for quite some time: Why doesn't the NTP message include the TAI - UTC offset used for the UTC timestamp in the message? Even a faultily configured server knows when it changes this offset, and it could help avoid the interpretation of incorrect warning bits. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Time math libraries, UTC to TAI
On 2017-01-02 18:55, Brooks Harris wrote about the correspondence | Date| MJD| NTP | NTP Timestamp | Epoch| | 4 Oct 1582 | -100,851 | -3 | 2,873,647,488 | Last day Julian | Ah, I think the table is correct - that's the infamous reset made by the Gregorian calendar to correct accumulated inaccuracies in the Julian and also, I believe, counted days at midnight, not noon, as Julian did (does). Sure, the Julian date of the day before the day with Gregorian date 1582-10-25 is 1582 Oct 04 -- but the epoch given in the table with the MJD value and the NTP timestamp values is obviously 10 days earlier: they all indicate Julian date 1582 Sep 24 and Gregorian date 1582-10-04, as I have noted earlier. The table indicates the (not usual) confusion about "omitted days" where it is unclear which numbers should be decreased (or increased) by ten. I do not want to be sarcastic but my managers would refuse to buy software when the spec (already) contains such blunders. And dates in the Julian calendar are taken to begin at midnight, as in the Gregorian calendar. It is the Julian day numbers used in astronomy that take integral values at noon epochs -- but they have nothing to do with the Julian calendar, except perhaps for the origin of the name. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WRC Final Acts
On 2015-12-06 12:26, Poul-Henning Kamp wrote about computer science organizations: There is nothing notable about that: There are no such ITU-compatible organizations they could work with. Isn't IFIP sufficiently international? Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News
On 2015-05-19 08:10, Stephen Colebourne wrote: A key point I've been making all along is that there needs to be an internationally agreed standard for how to do the smoothing. In Java I recommended UTC-SLS simply because it was at least a written up approach. (My preference is for a linear change because there is less chance of implementors getting it wrong). What for? I consider all these schemes just as internal representations of UTC time stamps, chosen according to special needs and constraints. We would not have so many different internal representations if there was no need for them. For data interchange and external storage, We have the standardized and well-understood notation of ISO 8601 for time stamps with leap seconds, such as 2015-06-30T23:59:60.2Z. Every internal representation must be convertible to and from that standard. In my opinion, no other standard is needed. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] My FOSDEM slides
On 2015-03-03 21:05, Martin Burnicki wrote about negative leap seconds: In the 7 year interval where no leap second was required/scheduled I heard several people saying we might have needed a negative leap second. Fortunately, this is not a matter of speculation. An easy way to see the trend of UT1 - UTC is to look at DUT1 (published in Bulletin D). DUT1 is an approximation to UT1 - UTC and has always stepped down (except, of course, at positive leap seconds), ever since the earliest Bulletin D available on the web (1991-06-20). Before a negative leap seconds would be scheduled, we would see DUT1 stepping up several times in a row, so there _is_ some advance warning. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS
On 2015-03-04 02:23, Steve Allen wrote on the epoch of TAI: Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967) A.R. Robins had been talking with Sadler and Smith and with that information in hand he wrote that atomic time was identical to UT2 at 1958-01-01 T 20:00:00 Z This, of course, disagrees with Guinot's memoir, but the various realizations of UT2 then differed by centiseconds and the different versions of atomic time were subsequently realigned by milliseconds. And that date of 1958-01-01 was decided ex post facto at the 1959 August meetings where the US and UK decided to try coordinating their broadcast time signals using cesium. So there really isn't an epoch for TAI. Well, there is not only personal recollections: RECOMMENDATION S 4 (1970) of the 5th Session of the Consultative Committee for the Definition of the Second: 4. The origin of International Atomic Time is defined in conformance with the recommendations of the International Astronomical Union (13th General Assembly, Prague, 1967) that is, this scale was in approximate agreement with 0 hours UT2 January 1, 1958. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-05 15:30, Warner Losh wrote on the determination of TAI - UT1: Now, back to the SI second vs the UT1 second. The UT1 second is 1E-8 or 1E-9 different from the SI second. Unless they are computing the results to 7 or more digits, the answers will be identical, no matter which definition of second you use. I don't understand. Measuring (mean solar day)/(1 d) is equivalent to measuring d(TAI - UT1)/d(UT1); if you assume the first quantity is 1, then the second becomes 0. Looking at a recent Bulletin B, the uncertainty for measurements of the rate d(UT1)/d(TAI) is of the order 1₁₀-9 (the IERS give 13 digits!), and typical uncertainty for LOD is around 10 µs/d. The IERS certainly won't fudge on their units. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-03 01:58, Warner Losh wrote: A common grid is an artificial construct that measurements from different clocks can be interpolated to. The top of second (or other phase) measurements place place the top of second in time. Interpolating to a grid places the time of each time scale at a fixed point on the grid so they can be compared by simple subtraction. The interpolation causes the local measurement device’s time scale to subtract out, and gives phase measurements at a specific time. For example, if UTC top of second for second 1 comes in at local time scale 1.1 and 2.1 and the UT1 PPS for second 1 comes in at 0.95 and 1.96[*], you can interpolate a phase at time 1.0 on the local time scale for each of these clocks and know the phase difference at 1.0. Do this for 1.0, 2.0, etc and you can make phase and frequency statements about UTC and UT1. [*] I know this is absurdly large, it should be 1.95001 or so) Is this required? In the general case it is, but in specific other cases it may not be absolutely required. It also generalizes to clocks whose frequency may not be 1Hz. This method also assumes that the local time scale (oscillator) is more stable than the acceptable error over the interpolation period, since all physical oscillators are imperfect. Thank you for the explanation! So a grid works as a kind of laboratory time scale to be used as a reference during measurements. You also replied to my statement: UT1 is a timescale that ticks 1 SI second when the Earth Rotation Angle increases by exactly (2·π rad)/86 636.546 949 141 027 072, Which it rarely does for any length of time. On the contrary, the fixed angular speed d(ERA)/d(UT1) is a defining property of UT1, and it is an auxiliary defining constant in the IAU 2009 system of constants. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-10-31 17:39, Brooks Harris wrote: Yes. Its primary timescale, sometimes called PTP Time, more properly the PTP Timescale, is a TAI-like counter (uninterrupted incrementing count of seconds). Note its origin, or epoch, is 1969-12-31T23:59:50Z, ten seconds before the POSIX the Epoch (if you take that to mean two years (2 x 365 x 86400) seconds before 1972-01-01T00:00:00Z (UTC), as NTP does). Just nitpicking: In [IEC 61588 of 2009-02. section 7.2.2] we read: The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.18 UTC. So you are off by about 2 s. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-10-30 23:57, Clive D.W. Feather wrote: The problem is that some people use UTC to mean TAI plus adjustments to keep it less than a second from UT1 while other people use UTC to mean the basis of legal time here. For the second set, using a new name for a different concept doesn't help. Yes. After leap seconds have been discontinued in (say) 2020, we will certainly need a short name for the time scale disseminated via radio broadcasts and NTP, and that has served as the basis for civil time, both before and after 2020. UTC comes to mind. We may also need a short name for TAI with leap seconds, especially if this is still used after 2020 and disseminated via new channels. Such as UTL for TAI with leaps. I believe that the naming issue can be solved easily once it is clear which time scales have to be distinguished and to be named. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
