On Mon, Jul 21, 2014 at 4:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> David G Johnston <david.g.johnston@gmail.com> writes:
> > This does seem kind of a harsh for a mis-understanding that one cannot
> > specify a hours offset as a valid timezone identifier. ISTM the OP was
> > trying to set the timezone to EDT by specifying a -04 hours and 00
> minutes
> > offset (- 04 00 =3D -0400 )...a 4-digit input like this shouldn't be
> > considered a -400 hour GMT offset...
>
> Perhaps so, but that's not the way it's been read by past PG releases.
> Changing that would be in the nature of a feature addition, not a bug fix=
,
> IMO. (In other words, if someone wants to do it, send in a patch ...)
>
>
=E2=80=8BAs you noted throwing an error is correct since an offset is not a
timezone - at least not in a way that is deterministic.
Since I don't have any example usages that would be convincing proof that
interpreting -0400=E2=80=8B as 400 hours is a bug the point becomes moot. =
In this
one instance neither 4 nor 400 is a reasonable answer. But given the
fundamental nature of a timezone anything that resolves to more than 12
absolute hours is incorrectly coded since values outside of +/- [0, 12]
have no meaning and either should throw an error or, in this case, be
treated in a more logical manner (-4:00)
There is a bug somewhere though you are welcome to argue whose
responsibility it is to correct - or at least accept that the aberrant
behavior is now intentional and being kept for backward compatibility
reasons even if it can result in absurd results - no matter how infrequent.
The code involved is already buggy since it crashes the server; this is
just another symptom that our current implementation is faulty.
David J.