On Wed, May 30, 2012 at 06:10:12PM -0400, Tom Lane wrote:
Currently, our datetime input code thinks that any UTC offset of more
than 14:59:59 either way from Greenwich must be a mistake. However,
after seeing Patric Bechtel's recent bug report, I went trolling in the
Olson timezone files to
Bruce Momjian br...@momjian.us writes:
On Wed, May 30, 2012 at 06:10:12PM -0400, Tom Lane wrote:
However, as pointed out by Patric, if you dump and restore an old
timestamptz value in one of these zones, it will fail to restore because
of the sanity check. I think therefore that we'd better
On Thu, Aug 30, 2012 at 04:51:02PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Wed, May 30, 2012 at 06:10:12PM -0400, Tom Lane wrote:
However, as pointed out by Patric, if you dump and restore an old
timestamptz value in one of these zones, it will fail to restore
Currently, our datetime input code thinks that any UTC offset of more
than 14:59:59 either way from Greenwich must be a mistake. However,
after seeing Patric Bechtel's recent bug report, I went trolling in the
Olson timezone files to see what are the largest offsets used there.
I found three
On May 30, 2012, at 3:10 PM, Tom Lane wrote:
However, as pointed out by Patric, if you dump and restore an old
timestamptz value in one of these zones, it will fail to restore because
of the sanity check. I think therefore that we'd better enlarge the
allowed range to 15:59:59 either way.
David E. Wheeler da...@justatheory.com writes:
On May 30, 2012, at 3:10 PM, Tom Lane wrote:
However, as pointed out by Patric, if you dump and restore an old
timestamptz value in one of these zones, it will fail to restore because
of the sanity check. I think therefore that we'd better
