[tz] isdst bug Europe/Dublin (tzdb-2019c)
Brian.Inglis at SystematicSw.ab.ca
Mon Dec 16 19:03:14 UTC 2019
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:
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:
and linked Bulletin Horaire scans, also:
"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
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.
More information about the tz