[tz] isdst bug Europe/Dublin (tzdb-2019c)
Clive D.W. Feather
clive at davros.org
Mon Dec 16 14:56:03 UTC 2019
Steve Summit said:
>> The times discussed in 184.108.40.206 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?
Those ones are in local time, so have years of varying lengths (*cough*
1751 and 1752 *cough*).
> Guy has, I think, tried to carefully decouple two aspects of the
> A. Does your time scale count leap seconds or not, and
This depends on what you mean by a leap second. And that is part of the
> 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.)
No. They look orthogonal at first glance, but they aren't.
> 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
[I'm wondering if that intended to have 3 before 4, based on the following
What I would have is, rather, the following:
C: Does your time scale count every second exactly once? A "no" answer
means that some seconds are not counted or are counted twice.
D: Does your time scale:
(1) use a monotonic count of seconds since some epoch
(2) use a broken-down style with the seconds field always stepping from
59 to 00 at the end of the minute
(3) use a broken-down style with the seconds field stepping from 58,
59, or 60 to 00 at the end of the minute, depending on the exact
C yes D 1 is a count of SI seconds since the epoch. I called it a count of
TAI seconds to avoid people confusing it with:
C no D 1, which is Posix time_t and which some people erroneously think is
a count of UTC seconds since the epoch. (It is approximately a count of UT1
seconds since the epoch, but I don't want to get into the SI versus sideral
C yes D 2 is TAI broken-down format.
C no D 2 is Posix broken-down format.
C yes D 3 is UTC broken-down format.
C no D 3 is, I hope, never used.
> 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.
That algorithm can convert between D 1 and D 2 for either C case, so long
as you don't mix them up.
> 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.
UTC is C yes D 3.
> 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.
Yes. I agree.
> 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
I think I agree with that as well.
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
More information about the tz