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 that could
> contain such dates alrea
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 like to do it in the next week or so
>> s
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? That is, would this be c
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 couple of months of beta
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 th
