From: Tom Lane <tgl@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.