Philip Paeps wrote:
Given the number of things this break, I would suggest backing the change out for now but pointing out in NEWS that it will come back say one year from now.
Replace the actual change by a comment that the current data is inaccurate pending software being fixed.
Thanks, this sounds like a good way to go. Proposed patch attached, and installed into the development version on GitHub. Presumably there should be a 2018c release quite soon, to get this temporary workaround out the door. (2018b has been prepared and published but not announced, since the problems with ICU and OpenJDK became apparent during the post-publication process.) There is a conflict between the goals of "let's not break anything" and "let's match civil timekeeping practice". I lean towards doing the latter as long as it doesn't cause too much trouble for the former. Here it seems like there is some trouble with ICU and OpenJDK, so delay seems advisable until fixes can be prepared. That being said, I don't want to wait indefinitely for these fixes. This is not a tzdb-specific issue, since POSIX requires support for negative DST (e.g., TZ='IST-1GMT0,M10.5.0,M3.5.0/1' for current Irish rules), which means that applications that reject negative DST are not portable to standard platforms configured for Irish time. The proposed patch continues to use the "IST is standard time" approach for Irish timestamps between October 1968 and October 1971, but I assume that's OK since that's what we did before.