Re: Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone.
От | David Johnston |
---|---|
Тема | Re: Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone. |
Дата | |
Msg-id | CAKFQuwa3LtgAqjP8=3NS0vb_sBqX2pWeXn7Yopc1izSN5Rv9RA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #11014: Postgres can be put into an error state by setting
invalid timezone.
|
Список | pgsql-bugs |
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.
В списке pgsql-bugs по дате отправления: