David G Johnston wrote
> On Mon, Jul 21, 2014 at 4:01 PM, Tom Lane <
> tgl@.pa
> > wrote:
>=20
>> David G Johnston <
> david.g.johnston@
> > 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 wa=
s
>> > 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.
>=20
> 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)
>=20
> 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.
>=20
> The code involved is already buggy since it crashes the server; this is
> just another symptom that our current implementation is faulty.
>=20
> David J.
Though pondering this additionally the actual coding to make -0400 be
interpreted as "-4:00" would indeed be a feature enhancement - though
accepting a result of 400 I would argue is a bug even if it is one we are
going to choose to live with in back branches for compatibility reasons. W=
e
seem to already agree that it should at least error out on a going-forward
basis.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-1=
1014-Postgres-can-be-put-into-an-error-state-by-setting-invalid-timezone-tp=
5812271p5812301.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.