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

[Guy Harris]

On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive at davros.org> wrote:

> Guy Harris said:
>>> [1] For example, I've ensured that the Bluetooth Mesh standard uses TAI
>>> internally for all timestamps, leaving the leap second mess to the
>>> periphery.
>> 
>> Yes, section 5.1.1 "Time" of
>> 
>> 	https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634
>> 
>> specifies that the base representation of times is the number of seconds that have elapsed since 1999-12-31T23:59:28 UTC. :-) :-) :-) :-) :-)
> 
> Yes. But ...
> 
>> (I.e., the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as an instant of time that has more zeroes in the way it's represented as TAI than in the way it's represented as UTC.  If it had been defined as the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC. that would still "leave the leap second mess to the periphery"; it would just mean that the count of seconds would be 32 seconds lower.
> 
> No, that's not the only way.

What's the other way?

>> By the way, how is TAI, represented as YYYY-MM-DDTHH:MM:SS TAI, defined?  Does it have a Gregorian-style calendar made up entirely of 86400-second days, so that most years are exactly 31,536,000 seconds long, with some years being exactly 31,622,400 seconds long?
> 
> 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.

And the same would be true if it counted the number of seconds that have elapsed since 2000-01-01T00:00:00 UTC.

>> If so, then there are at least four different flavors of time stamp, with "time stamp" defined as "label assigned to an instant of time":
>> 
>> 	1) "TAI-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, with non-leap years being exactly 31,536,000 seconds long and leap years being exactly 31,622,400 seconds long, so that SS goes from 00 to 59, never to 60;
> 
> That's what Mesh uses when handling a "broken-down" time. Hence "TAI".

Preview doesn't report the word "broken" anywhere in the spec.  The times discussed in 5.1.4.2 Schedule Register presumably are, when no wildcards are involved, local dates/times, with a time stamp being a Gregorian-style YY-MM-DDTHH:MM:SS, and with non-leap years being either 31,536,000, 31,536,001, or 31,536,002 seconds long, and with leap years being either 31,622,400, 31,622,401, or 31,622,402 seconds long (which might disagree with most real-world clocks, as those clocks probably behave as if you had a UTC calendar and a clock that ticks like TAI, in the sense that it always goes from 23:59:59 to 00:00:00, but that's some number of seconds off from TAI).

The Time state includes TAI-UTC Delta Current, TAI-UTC Delta New, and TAI of Delta Change; those require dealing with leap seconds.

>> 	3) counts of seconds since a specified epoch, with the count including leap seconds;
> 
> And that's what Mesh uses when just counting seconds. I agree that it
> doesn't matter whether you could TAI seconds or UTC seconds, because
> they're exactly the same.

I.e., nothing prevents such a clock from

>> Note that 3) could use either a TAI-style calendar+clock or a UTC-style calendar+lock to specify the epoch; the same is true of 4).)
> 
> True. But that excludes your item 1.

3) and 4) both completely exclude 1) and 2) - they're all different schemes for time-stamping instants of time, so 1) excludes 2), 3), and 4), 2) excludes 1), 3), and 4), 3) excludes 1), 2), and 4), and 4) excludes 1), 2) and 3).  For 1) and 2), a time stamp would look like 2019-12-15T09:54:56; for 3) and 4), a time stamp would look like 1576317243.

Both 3) and 4) could use either a 1)-style stamp or a 2)-style stamp in whatever spec defines the epoch.

(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" in sequence with no spaces between them or includes the letters "U", "T", and "C" in sequence with no spaces between them.)