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

[Steve Summit]

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.

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

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

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

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

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.

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