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

[Guy Harris]

On Dec 13, 2019, at 2:13 PM, Clive D.W. Feather <clive at davros.org> wrote:

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

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

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

	2) "UTC-style calendar+clock", with a time stamp being a Gregorian-style YYYY-MM-DDTHH:MM:SS, but with some years being 31,536,001 seconds, 31,622,401 seconds long, or 31,622,402 seconds long, depending on how many leap seconds there were during the year, so SS could occasionally go from 59 to 60;

	3) counts of seconds since a specified epoch, with the count including leap seconds;

	4) counts of non-leap seconds since a specified epoch.

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