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

[Clive D.W. Feather]

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.

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

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

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

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

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