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

[Clive D.W. Feather]

Steve Summit said:
>> 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?

Those ones are in local time, so have years of varying lengths (*cough*
1751 and 1752 *cough*).

> Guy has, I think, tried to carefully decouple two aspects of the
> question:
> 
> A. Does your time scale count leap seconds or not, and

This depends on what you mean by a leap second. And that is part of the
problem.

> B. Does your representation use broken-down times ("calendar +
>    clock"), or monotonic counts of seconds since an epoch?
>
> I agree that those issues are orthogonal.  (I'm also going to
> ignore for now the side question of whether the epoch mentioned
> in "B" is defined as a UTC or TAI timestamp.)

No. They look orthogonal at first glance, but they aren't.

> So when Guy said "there are at least four different flavors of
> time stamp", I think his flavors map onto my two aspects A and B
> with this little truth table:
> 
>   A    B
>  no   b-d   1) TAI-style calendar+clock
>  yes  b-d   2) UTC-style calendar+clock
>  no   mono  4) counts of non-leap seconds since a specified epoch
>  yes  mono  3) counts of seconds since a specified epoch,
>                with the count including leap seconds

[I'm wondering if that intended to have 3 before 4, based on the following
text.]

What I would have is, rather, the following:

C: Does your time scale count every second exactly once? A "no" answer
means that some seconds are not counted or are counted twice.
D: Does your time scale:
   (1) use a monotonic count of seconds since some epoch
   (2) use a broken-down style with the seconds field always stepping from
       59 to 00 at the end of the minute
   (3) use a broken-down style with the seconds field stepping from 58,
       59, or 60 to 00 at the end of the minute, depending on the exact
       date-time.

C yes D 1 is a count of SI seconds since the epoch. I called it a count of
TAI seconds to avoid people confusing it with:

C no  D 1, which is Posix time_t and which some people erroneously think is
a count of UTC seconds since the epoch. (It is approximately a count of UT1
seconds since the epoch, but I don't want to get into the SI versus sideral
seconds debate).

C yes D 2 is TAI broken-down format.

C no  D 2 is Posix broken-down format.

C yes D 3 is UTC broken-down format.

C no  D 3 is, I hope, never used.

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

That algorithm can convert between D 1 and D 2 for either C case, so long
as you don't mix them up.

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

UTC is C yes D 3.

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

Yes. I agree.

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

I think I agree with that as well.

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