[tz] isdst bug Europe/Dublin (tzdb-2019c)

Sat Dec 14 19:23:34 UTC 2019

On Dec 14, 2019, at 8:00 AM, Steve Summit <scs at eskimo.com> wrote:

> Guy Harris wrote:
>> On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:
>>> Guy Harris said:
>>>> ...the only way in which it "uses TAI" rather than using UTC is that
>>>> the epoch is defined as...
>>> 
>>> No, that's not the only way.
>> 
>> What's the other way?
> 
> I'm guessing that the other way boils down to (however you try to
> represent dates and times) *not* having any leap seconds anywhere
> -- that is, unambiguously working in TAI everywhere, and drifting
> farther away from UTC every time there's a leap second.

Meaning, for example, that the time and date fields in 5.1.4.2 "Schedule Register" represent TAI times rather than local times?

The time stamps described in 5.1.1 "Time" are "type 3" in my list - a count of all elapsed seconds, including leap seconds, since a given epoch.

If you're keeping UTC - not the not-quite-UTC called "POSIX time" - you *also* need a count of all elapsed seconds, including leap seconds, since a given epoch, given that UTC time, like TAI time, changes even during positive leap seconds; it just happens to change in a different way.

In TAI, it always goes, presumably, from {day} 23:59:59 TAI to {next day} 00:00:00 TAI, regardless of whether a positive leap second is inserted at that instant of time or not.

In UTC, it goes from {day} 23:59:59 UTC to {same day} 23:59:60 UTC, and in the *next* second goes to {next day} 00:00:00 UTC.

It's only in times like "POSIX time" where it stays stuck at 23:59:59, or is slowed down, or whatever form of tweaking is done to pretend that every day is 86400 seconds long; that's not done in real UTC.

>>> Yes, and that's a big part of "avoiding the mess" - you don't
>>> worry about time zones *or* leap seconds.
>> 
>> ...unless you need to convert a Bluetooth Mesh time stamp to UTC.
> 
> Right.  I imagine that's a pretty big problem.
> 
>> The times discussed in 5.1.4.2 Schedule Register presumably are [...]
>> with non-leap years being either 31,536,000, 31,536,001, or 31,536,002
>> seconds long
> 
> I wouldn't presume that at all.  If it's doing TAI, if it's not
> counting leap seconds, why would you presume years of other than
> 31,536,000 or 31,622,400 seconds?

Because, in that section, it's *not* doing TAI:

	5.1.4.2 Schedule Register

	The Schedule Register state is a 16-entry, zero-based, indexed array of 76-bit values formatted as Scheduled Time. Each entry represents a state-changing event. *Time and date fields represent local time.*

> 
>> The point is that, in a time stamping mechanism that stamps times with
>> counts of seconds since an epoch, whether the count includes leap
>> seconds is independent of whether the specification for the epoch
>> includes the letters "T", "A", and "I" ...
> 
> There may be additional subtleties here that I'm overlooking,
> but to me, this discussion cuts to the heart of the whole eternal
> leap second imbroglio.
> 
> Guy has, I think, tried to carefully decouple two aspects of the
> question:
> 
> A. Does your time scale count leap seconds or not, and
> B. Does your representation use broken-down times ("calendar +
>   clock"), or monotonic counts of seconds since an epoch?

What does "count leap seconds" mean in this context?

If you have a B-style representation, it means "does that count increase during a positive leap second?" (we'll ignore negative leap seconds here).

If you have an A-style representation, and it's TAI or UTC, it "counts leap seconds" in the sense that "the clock value changes even for the leap second and, if it overflows, the calendar value changes as well".  The difference between TAI and UTC in that regard is in the fashion in which the clock value changes.  The clock value changes in the same fashion, all the time, in TAI; it doesn't change in the same fashion, all the time, in UTC, *and the way in which it will change in the future is not predictable past a certain point* - you have to wait for an IERS Bulletin C to come out for that point before you can predict.

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?)

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).

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).

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, every one of those seconds occurs in UTC as well, 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.

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.

> 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.

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.

> If you try to represent UTC using a monotonic count of seconds,
> you have to either (a) ignore leap seconds after all (as Posix
> does, but which totally contradicts those words "with the count
> including leap seconds" in the definition of (3)), or (b) use
> a kludgey and non-obvious (and non-Posix) mapping between your
> monotonic time and broken-down calendar+time, a mapping which
> always requires you to have a perfect leap second table available.
> 
> And in fact, if you try to do (b), I believe that you are *not*
> really doing UTC, after all -- you are basically doing TAI
> (perhaps with a slightly different epoch), and misleadingly
> calling it UTC.

If you are doing (a), you're not doing UTC either, given that POSIX can't distinguish between, say, 30 June 2015, 23h 59m 59s UTC and 30 June 2015, 23h 59m 60s UTC.

(a) can't even do UTC correctly for *past* events.  (b) *can* do UTC correctly for past events if you have a leap second table available that includes all announced leap seconds as of now - I think there may even be some sample code to do that. :-)  What it can't do is handle UTC for *future* events, as a "perfect" leap second table requires perfect knowledge of the future, and we all what somebody (Karl Kristian Steincke?) said about predicting:

	http://quoteinvestigator.com/2013/10/20/no-predict/

TLDR: "you can't do UTC for arbitrary times in the future without running the risk of having to adjust something before the event".  (Well, with sufficient thiotimoline used in your clock you might. :-))

> You are engendering just as much confusion as
> the Posix time_t definition does.  A monotonic count of seconds
> is simply not an appropriate representation for UTC.  The only
> proper representation(s) of UTC are those that separate the date
> from the time, so that they can cleanly, honestly, openly, and
> explicitly accommodate those pesky days of other than 86400
> seconds.

You cannot predict what the broken-down UTC label for an event N seconds in the future will be, if N is sufficiently large that it will be past a point at which a leap second might be introduced and for which the IERS hasn't announced whether there will be a leap second or not - the UTC label depends on whether a leap second will be inserted there or not.

So UTC - and local civil time, if based on UTC - isn't a good way to label events sufficiently far in the future (as in, right now, any event happening at or after the end of 30 June 2020), if you can't live with being a few seconds off.

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).