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

[Clive D.W. Feather]

Guy Harris said:
> 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

It's a while since I was involved in Mesh, and it's possible that they've
managed to mess things up since then. But, let's see ...

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

Okay, that statement does indeed pick a convenient epoch for counting
seconds. It means the the function to map the 40-bit seconds count (and 8
bit subsecond count) to a "broken-down" time in TAI is easy.

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

Which is done "on the periphery". Note the use of zero in various fields to
indicate that the device doesn't have zone or leap second information.

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

Also true, but it seems cleaner to have the epoch be a round point in TAI,
rather than in UTC, given that you're using TAI internally. Note the
following paragraph:

"To allow Mesh devices to refer to UTC or local times, devices need to be
aware of the past, present, and predicted changes to the TAI-UTC Delta (the
number of seconds between TAI and UTC) and to the local time zone offset
(e.g., in Seattle, USA, the local time is exactly 7 hours behind UTC for
part of the year and 8 hours behind UTC for the rest of the year). Because
these two values can change at any time for physical or political reasons,
they are not hard-coded into this specification. Instead, they are
communicated to all nodes in the mesh provided that at least one device has
the information."

More "periphery" stuff, since most uses won't use those offsets.

An algorithm is also given for converting TAI seconds since the epoch to a
UTC "broken-down" time. Setting E and F to zero will give you a TAI
"broken-down" 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 term "broken-down time" is common - or, at least, I thought it was - to
refer to the "YYYY-MM-DD hh:mm:ss" format as opposed to "(some) (sort-of)
seconds past the epoch".

But it's possible that they stopped doing this after I stopped being
involved.

> 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 Scheduler is part of the app you run on your phone, or whatever. As it
says, the fields are in local time.

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

But those are only generated by the device that knows them and are only
used to present values in local time or to convert local time to SI seconds
past the epoch. Most devices in the mesh don't do that.

The Scheduler app converts the local times into TAI-past-the-epoch to send
out "turn on at this time" messages.

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

s/could/call them/

In fact, "SI seconds" might have been better. One reason for using "TAI"
rather than "UTC" is that it makes it clear that all seconds are included
rather than the Posix perversion of calling it UTC and then ignoring some
of them.

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

True, *if* people don't misunderstand.

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