Earlier this week I pushed tzdata 2018d into our tree, expecting that that would be the current IANA timezone data for next week's releases. Well, I was wrong; today they pushed out a new version:
https://mm.icann.org/pipermail/tz-announce/2018-May/000050.html on account of North Korea deciding to change their time zone with a week's notice. Ordinarily I'd just absorb 2018e and be done with it. But I am feeling hesitant about this update, because it also incorporates this change: Bring back the negative-DST changes of 2018a, except be more compatible with data parsers that do not support negative DST. Also, this now affects historical time stamps in Namibia and the former Czechoslovakia, not just Ireland. The main format now uses negative DST to model time stamps in Europe/Dublin (from 1971 on), Europe/Prague (1946/7), and Africa/Windhoek (1994/2017). This does not affect UT offsets, only time zone abbreviations and the tm_isdst flag. Also, this does not affect rearguard or vanguard formats; effectively the main format now uses vanguard instead of rearguard format. Data parsers that do not support negative DST can still use data from the rearguard tarball described below. As the announcement hints, this "negative DST" business was sufficiently controversial that the initial attempt to push it was rescinded, on the grounds that negative DST offsets might break people's software, and some lead time was required to deal with that. Basically, the point here is that it seems that in Ireland, legal "standard time" is what they use in summer, and in winter they use "daylight savings" time that is one hour behind standard time, rather than one hour ahead as is usually meant by "daylight savings". Up to now the IANA database has just ignored the fact that "IST" is legally "Irish Standard Time" not "Irish Summer Time", but now they want to represent it properly. >From our point of view, the question is whether any applications are likely to get confused if the "is_dst" column shown in pg_timezone_names and pg_timezone_abbrevs is turned on for offsets that are one hour behind their zone's "regular" time instead of one hour ahead. I do not think anything inside PG will get confused (though I could be wrong about that). Application-level problems of this sort seem possible but not very likely. We have a couple of alternatives: 1. Bull ahead and push tzdata 2018e into our tree, and ship that with Monday's releases. I am scared of this choice, because there is basically no time remaining to detect or recover from any problems. 2. Delay applying 2018e until after next week's releases, so that we have three months for any problems to get noticed. (Also, 2018e could go out with v11 betas, so that we can expect there would actually be some field testing of it before it'd be released in back branches.) 3. As the announcement mentions, there's a "rear guard" version of the tzdata files in which the negative-DST changes haven't been made. Perhaps we could use that version for awhile, maybe only in the back branches. But eventually we'd have to change --- it's pretty clear that the IANA crew isn't going to maintain this "rear guard" format forever --- and it's not clear that postponing the pain would make anything better. An important consideration here is that for a very large fraction of our users, our choices here won't affect things in the least: any package that uses --with-system-tzdata is going to be subject to the platform's decisions about which tzdata to use and when to push it, not ours. We can be pretty certain that bleeding-edge-loving platforms (e.g. Gentoo) will push negative-DST-using tzdata soon. Therefore, our code has to be prepared to work with that even if we don't ship it. This leads me to think that we'd best incorporate 2018e into HEAD and ship it in 11beta, regardless of what we do for the back branches. I don't particularly want to get into a situation where we're shipping different tzdata in v11+ than in older branches; that'd be a maintenance nightmare. So I'm not enamored of the variants of option 3 that would have us doing that. But the variant in which we ship rear-guard data in all branches seems like it's just postponing a problem that we can't postpone forever. On balance I'm leaning towards option #2, ie go with the new data but wait till just after the minor releases. Thoughts? regards, tom lane
