On 2019-12-14 12:23, Guy Harris wrote:
On Dec 14, 2019, at 8:00 AM, Steve Summit wrote:
Guy Harris wrote:
On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather wrote:
Guy Harris said:
ITU-R Recommendation TF.460-6 says:
2 Leap-seconds
2.1 A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.
2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month (see Annex 3).
but where 1) the form HHh Mmm SSs for time stamps specified for UTC, 2) is that also specified for TAI?, 3) is it stated anywhere how days are indicated in this context (YYYY-MM-DD? DD MMMMM YYYY?)
What that Recommendation says is
B International atomic time (TAI)
The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971).
C Coordinated universal time (UTC)
UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds.
The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to ensure approximate agreement with UT1.
which, at most, says that, *for example*, TAI is in the form of days (presumably days that are always exactly 86400 seconds long)), hours. minutes, and seconds from "the origin 1 January 1958" (does that mean "midnight, 1 January 1958"?). If, in fact, "days" correspond to exactly-86400-second-long days, and "the origin 1 January 1958" is "midnight, 1 January 1958", TAI could also be represented as a scale of seconds since the origin 1 January 1958, with conversion between those two scales being straightforward (division and remainder to go from the second scale to the first, multiplication and addition to go from the first scale to the second, given that there are no leap seconds, month lengths, or leap years to worry about).
Just to muddy things further, in an article in "Polar Motion: Historical and Scientific Problems", ASP Conference Series, Vol. 208, also IAU Colloquium #178. Edited by Steven Dick, Dennis McCarthy, and Brian Luzum. (San Francisco: ASP) ISBN: 1-58381-039-0, 2000., "History of the Bureau International de l'Heure", Guinot, B., p.181: http://articles.adsabs.harvard.edu/pdf/2000ASPC..208..175G#page=7 states in the third paragraph: "By convention, all integrated atomic times, at BIH and elsewhere, were set so that an event at 1958 January 1, 0h UT2, receive the same date in UT2 and atomic time scales. However, the observatories used their own values of UT2: that explains that longitude errors of a few 0.01s appear in the local independent time scales, as they are presently realized." Reading that page and the next, it is apparent that AT, AM, A3, TA, TAI frequencies have been tweaked and steered to maintain consistency with earlier timescales and standards as well as between organizations. See also: https://www.ucolick.org/~sla/leapsecs/taiepoch.html and linked Bulletin Horaire scans, also: https://www.bipm.org/en/bipm-services/timescales/tai.html "The long-term stability of TAI is assured by weighting the participating clocks. The scale unit of TAI is kept as close as possible to the SI second by using data from those national laboratories which maintain the best primary caesium standards." so all should bear in mind that TAI is a synthetic timescale calculated and adjusted in arrears, so shares some of the same problems as leap seconds but occurring at higher precisions. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.