[tz] isdst bug Europe/Dublin (tzdb-2019c)
Clive D.W. Feather
clive at davros.org
Mon Dec 16 16:26:24 UTC 2019
Guy Harris said:
> So are A-style representations defined for both UTC and TAI? 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?)
Hmm.
> 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"?).
That says rather less than I expected. Equally, it doesn't say that much
about UTC either.
I would have thought "differs from it by an integer number of seconds" only
makes sense if they use the same representation when calcualting the
difference.
> If, in fact, "days" correspond to exactly-86400-second-long days,
I think they do.
> 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).
Okay, using a JD-style day count. But ...
> Can TAI also be represented as an absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day? If so, are there any specified rules for that? (Conversion to or from that scale from either of the scales mentioned in the previous paragraph is a little more work, as you'd have to worry about month lengths and leap years).
I think that was probably ignored as an issue, since "everyone knows" how
the calendar works. The ISO 8601 rules for date sequences work perfectly
well and there's no reason to re-state them.
> And in what ways could the UTC scale be represented? The "differs from it by an integral number of seconds", with the difference varying over time, would presumably be a difference between the "absolute Gregorian-style date (year, month of year, day of month) and a time of hours, minute, and seconds since the beginning of that day" representations of TAI or UTC, given that "It corresponds exactly in rate with TAI" means that, for the "days, hours, minutes and seconds from the origin 1 January 1958" definition of TAI,
Okay so far.
> every one of those seconds occurs in UTC as well,
But some of them with an xx:xx:60 label (and, in theory, some xx:xx:59
labels missing).
> so if you represent UTC as a count of days, hours, minutes, and seconds from some origin, or just as a count of seconds from that origin, the difference between the two scales, in seconds, is the difference between the origins, in seconds.
I've always read it as the difference being the difference in broken-down
time labels (xx:xx:05 v xx:xx:41, or whatever) and *not* a difference in
seconds since some epoch.
> Annex 3 of that recommendation, "Dating of events in the vicinity of a leap-second", shows events being dated "30 June, 23h 59m 60.6s UTC"; as it's an example, the year is omitted, so presumably the "30 June" would have a year number after it for a real event, i.e. an absolute Gregorian-style date.
More evidence that they viewed the calendar bit was "well-known".
> > Me, I would say that (1) and (4) are completely compatible --
> > they're two different representations for the same underlying
> > time scale. You can perfectly interconvert between them using
> > the same algorithm Posix defines for time_t.
> >
> > When it comes to UTC, however, (2) and (3) are most definitely
> > not compatible. Personally, I believe that (2) is the *only*
> > way to represent UTC. I believe -- Posix time_t most assuredly
> > notwithstanding -- that (3) is an abomination.
>
> (2) and (3) are both problematic.
>
> With (2), time stamps for events defined to occur at a specified sufficiently large number of seconds in the future cannot be predicted. That includes all events with times specified by a (1)-style or (4)-style time stamp if those times go past what the IERS has specified.
Of course. This is the basic "leap seconds problem".
> With (3), some time stamps cannot be specified - including time stamps for events in the *past*, such as an event occurring on 30 June 2015 at 23h 59m 60s UTC.
And that's the Posix problem.
[...]
> So if we want to describe *any* timekeeping scheme that represents times in a format that is, or can trivially be converted to and from without loss of information, a count of seconds, including leap seconds, since some epoch, as "TAI", OK. That does *not*, of course, mean that the epoch needs to be expressed as a TAI time stamp; "seconds, including leap seconds, since 1970-01-01 00:00:00 UTC" would then be a representation of TAI (given that we know what instant of time was labeled 1970-01-01 00:00:00 UTC - no knowledge of the future is needed there).
Okay; I don't dispute that either.
Bluetooth Mesh used a TAI 00:00:00 epoch to simplify the conversion between
seconds-since-epoch and hh:mm:ss in people's minds. I accept that the only
difference between that and a UTC 00:00:00 epoch is a constant offset equal
to TAI-UTC at the moment of the epoch.
--
Clive D.W. Feather | If you lie to the compiler,
Email: clive at davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
More information about the tz
mailing list