On Mon, Jul 18, 2016 at 9:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> When I updated our copy of the IANA timezone library back in March
> (commit 1c1a7cbd6), I noted that we ought to consider back-patching
> those changes once they'd settled out in HEAD. Now that the code
> has survived a couple of months of beta testing, I think it is time
> to do that.
> I went through the IANA announcement archives
> to get a summary of what's changed since the tzcode 2010c release
> that we last synced with. Attached is a list of code changes that
> seem potentially significant to us. There are at least two ticking
> time bombs in there, namely zic feature additions that IANA has not
> yet started to use in the tzdata files, but presumably will start
> using at some point, else why would they put them in? (These are
> the extension to allow four DST transitions per year and the addition
> of %z escapes in TZ abbreviations.) Whenever they do start using them,
> we'll be unable to apply tzdata updates to unpatched back branches,
> because our old copy of zic will fail to compile the tzdata files.
> There are also several bug fixes that affect interpretation of dates after
> 2037, a year that's getting closer all the time. And there are some
> changes that affect reading of zic data files, which could affect
> unpatched back branches that are built with --with-system-tzdata,
> since those might be fed updated data files even if we do nothing.
> So I think it behooves us to apply these changes to the back branches
> while we can still do it in a leisurely fashion, rather than waiting
> until our hands are forced. I'd like to do it in the next week or so
> so that we can get in a little bit of buildfarm and manual testing
> before the next set of back-branch releases in August.
> Thoughts, objections?
This seems reasonable. Except the 2016e one which hasn't seen master yet.
But it would definitely make sense to try to get 2016e into 9.6 ASAP, so we
can get it into the next beta/rc (not the one on it's way now, but the one