We're not lax enough about maximum time zone offset from UTC
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 entries that are further out than that:
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31
Zone America/Juneau 15:02:19 - LMT 1867 Oct 18
Zone America/Metlakatla 15:13:42 - LMT 1867 Oct 18
These are all ancient history of course; it does not appear that any
zones *currently* use offsets larger than +/- 14 hours, which if memory
serves is what we considered when we set the existing sanity limit.
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.
regards, tom lane
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.
Should you be validating them on a per-time zone basis? Or does it matter?
David
"David E. Wheeler" <david@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 enlarge the
allowed range to 15:59:59 either way.
Should you be validating them on a per-time zone basis? Or does it matter?
We can't really --- a given input string should be valid, or not,
independently of what TimeZone is set to. If we change that we're far
too likely to break scenarios that work now.
regards, tom lane
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 see what are the largest offsets used there.
I found three entries that are further out than that:# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31
Zone America/Juneau 15:02:19 - LMT 1867 Oct 18
Zone America/Metlakatla 15:13:42 - LMT 1867 Oct 18These are all ancient history of course; it does not appear that any
zones *currently* use offsets larger than +/- 14 hours, which if memory
serves is what we considered when we set the existing sanity limit.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.
Any status on this?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Bruce Momjian <bruce@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 enlarge the
allowed range to 15:59:59 either way.
Any status on this?
Shipped in last week's updates.
regards, tom lane
On Thu, Aug 30, 2012 at 04:51:02PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@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 enlarge the
allowed range to 15:59:59 either way.Any status on this?
Shipped in last week's updates.
Thank you.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +