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

Robert Elz kre at munnari.OZ.AU
Fri Dec 13 00:17:16 UTC 2019

    Date:        Thu, 12 Dec 2019 09:29:03 -0700
    From:        Brian Inglis <Brian.Inglis at SystematicSw.ab.ca>
    Message-ID:  <4e191681-6342-a5d3-e539-945a50fd11c3 at SystematicSw.ab.ca>

  | I preferred whichever reference used the terms "standard time"
  | and "alternative time",

That was POSIX, before it was changed (not yet published, but applied,
"alternative time" will no longer appear when the next edition is pubished)
based upon some input from this direction.

But, while I agree it was better, it's not good enough either - first
because there's not just two, and second, because there's no point giving
these things a name - whatever time it is (commonly agreed, whether
legislatively backed or not) is "standard time" - that's what it means
to be "standard".   The only other thing we can (at least currently) rely
upon is that there is a current offset from UTC (ie: that UTC is stable,
and the time anywhere is, for a short while anyway, a constant offset
from UTC - positive or negative (or 0)).

Some juristictions provide names for the various times, mostly for convenience
around the transitions, but none of them are very useful, and here we really
cannot rely upon any such thing existing.

tm_isdst was originally just intended as an index into tzname[] to get
the (assumed always to exist) "name" of the current time (nb: not timezone).
Both of the assumptions there are demonstrably false, first that there is
a name to get, and second that there are just two (0 or 1 in tm_isdst).
tzname[] is also an interface disaster, and should be retired, and if it
is, the sole rational reason for tm_isdst to exist at all will vanish, and
it can be deleted as well.

[The addition of -1 as a tm_isdst value "don't know" when it is used as
input to mktime() came later - as did mktime - that was a hack, still is].

But please people, we have had this discussion over and over, nothing is
going to change anytime in the forseeable future, neither to correct any
"bugs" that appear to exist (they don't - or not in this area) nor to
actually make the interface more sane.

There's no point continually discussing it.


More information about the tz mailing list