[tz] Irish Standard Time vs Irish Summer Time

[Robert Elz]

  From: Tom Lane <tgl at sss.pgh.pa.us>
  Date: Fri, 19 Jan 2018 01:07:18 -0500
  Subject: Re: [tz] Irish Standard Time vs Irish Summer Time

  | How, exactly, will it improve anyone's life to change from "tm_isdst = 1
  | means that local time is advanced" to "tm_isdst means something, but
  | nobody knows what"?

The issue is that "means the local time is advanced" is, and always
has been, an invalid assumption based uon apparent observed behaviour,
rather than any definition.

In the past software sometimes assumed it meant "advanced by 1 hour"
but that's been broken for so long that it is generally been forgotten
now (I hope.)

The original use of tm_isdst was an as index into the tzname[] array
to allow software to get the correct abbreviation to display.  For
that purpose it makes not one iota of difference what the offset is
for either of the (just two) possible zone names.   (Originally of
course there was no tzname[] and the names were built into libc, but
the purpose was the same, it passed info to asctime() from localtime()).

More recently it has also been used in the other direction, as a hint
to mktime() which result to pick in the cases of ambiguous localtimes.

That's it.   Anything using it for any other purpose is broken and
ought to be fixed.

More than that, as there are (for purpose 1 above) just two values
possible (0 and 1) and there is no such limit on the number of
different abbreviations which might apply at different times in
one of what we call a timezone (that is, a juristiction might decide
to have winter time, spring time, summer time, and autumn time, all
with different offsets, and give them all different abbreviations),
so we really should be deprecating tm_isdst for even this purpose, and
rely upon tm_zone and tm_gmtoff instead, which are a much better way
to pass the required info out from localtime ... any implementations
which are yet to add those fields to struct tm (they were created
decades ago - there really is no excuse after all this time) should
simply be regarded as broken and unusable.

The fundamental problem here is software writers making assumptions
about how (human represented) time works - every one of those I have
ever seen (that I can think of anyway) has turned out to be wrong,
and if there are any that remain, they will break one day (like perhaps
7 days in a week... one day, someone will change that, somewhere!)
We already know (yet the assumption is still made) that years are not
required to have 12 months, as if you go far enough back into the
past, they didn't.   Perhaps in the future they won't again (13 is
closer to astronomical reality).

The answer to this is fairly simple - stop making assumptions, any
of them.

That includes to stop assuming that there is one "standard" time, and
that any other time is some variation (and especially that the variation
must have an advanced offset over the "standard" time offset).  "Standard"
time is simply the time that is agreed it is *now* (at any time of the
year) - that's what it means to be a standard.   Of course, jurisdictions
are free to label one of their offsets as "standard" and another as
"summer" or "winter" (or even the absurd "daylight savings") if they
want, but those are just names, and should have no bearing on anything
other than for display to humans.

  | On the other hand, I've spent quite a lot of effort over the past couple
  | of years dealing with the random-seeming changes in zone abbreviations,
  | and none of that churn has made anyone's life better that I'm aware of.

Why?   I am not a fan of those changes, I don't seem them accomplishing
anything, but if any software breaks because of them, it was already
broken, just the breakage was hidden.  (Just like the old Y2K issues,
where software that assumed 2 digits for a year was always broken, but
just happened to work when all that mattered was the second half of
the 20th century (CE).   Software that assumes 4 digit years is just
as broken - there were years before 1000, and there will be years after
9999 (we hope).)

The zone name abbreviations should be used for no other purpose than
to display to users to give them a slightly more warm and fuzzy feeling
that they know (or perhaps don't know) what local time is being shown
to them than -0500 does.

Anything more than that is simply broken (with the, perhaps, one
exception, of e-mail header parsing as long as only those abbreviations
that were specified in rfc822 (now mostly deprecated for use) are
recognised - and perhaps some other similar uses, where some other
standard says what means what -- where what tzdb gives for any
abbreviation is 100% irrelevant.)

  | I think it's past time that the tz database realizes, and acts on,
  | the fact that it's a de facto standard, and whacking around the
  | standard has high costs.

I agree with that.   However, we have the issue that people are simply
guessing what what is promised, and what is just changeable data.
The abbreviations are, and always have been, subject to change at any
time - that they did not frequently change (though there were always some
changes) is more just an accident of history than something that can be
relied upon.

kre

ps: in case it is not obvious, I agree with the changes made for Ireland,
they're correct, as much as what appears in tm_isdst is ever "correct".
I'm not sure I'd even bother delaying the effect, and certainly not for
as long as a year - I could understand backing them out of 2018b, but they
should be back again in 2018c, and remain after that.  I'm guessing that c
is likely to appear around March sometime, so all you people with software
that is abusing the field, or making assumptions about it, have a couple of
months to get it fixed.  That is, just stop using it at all.  For localised
translations of the zone abbreviations, use the zone (America/New_York or
whatever it happens to be) with tm_zone field as a key (or perhaps tm_gmtoff)
to look up the localised replacement for tm_zone.