Re: [HACKERS] Updating our timezone code in the back branches

Greg Stark writes: > On Mon, Jul 18, 2016 at 8:09 PM, Tom Lane wrote: >> There are also several bug fixes that affect interpretation of dates after >> 2037, a year that's getting closer all the time. > Does this represent a data incompatibility for databases

Re: [HACKERS] Updating our timezone code in the back branches

Magnus Hagander writes: > On Mon, Jul 18, 2016 at 9:09 PM, Tom Lane wrote: >> 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

Re: [HACKERS] Updating our timezone code in the back branches

On Mon, Jul 18, 2016 at 8:09 PM, Tom Lane wrote: > There are also several bug fixes that affect interpretation of dates after > 2037, a year that's getting closer all the time. Does this represent a data incompatibility for databases that could contain such dates already?

Re: [HACKERS] Updating our timezone code in the back branches

On Mon, Jul 18, 2016 at 9:09 PM, Tom Lane 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

[HACKERS] Updating our timezone code in the back branches

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