Re: Bug in tm2timestamp

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug in tm2timestamp
Дата
Msg-id 13199.1362426885@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Bug in tm2timestamp  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Bug in tm2timestamp  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Bug in tm2timestamp  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> AFAICT, there's a bug in tm2timestamp(). You can't do this:
> postgres=# select '1999-12-31T24:00:00'::timestamptz;
> ERROR:  timestamp out of range: "1999-12-31T24:00:00"

> But that's a perfectly legal date. It works fine for any other year -
> and AFAICT this is because of the POSTGRES_EPOCH_JDATE being
> 2000-01-01.

> The check in 1693 and forward comes with *result=0 and date=-1 in this
> case, which AFAICT is fine.

Meh.  Looks like I fixed this back in 2003, but didn't fix it right.
Will try again.

> I'm not entirely sure what that check is guarding against (which may
> be because I just came off a flight from canada and don't really have
> the brain in full gear ATM). Perhaps it just needs an extra exclusion
> for this special case?

I think we should just tweak the tests so that if "date" is 0 or -1,
we don't consider it an overflow even if the time adjustment pushes
the result to the other sign.

BTW, it strikes me that it's a bit silly to go to all this effort
here, and then ignore the possibility of overflow in the dt2local
adjustment just below.  But we'd have to change the API of that
function, which I don't especially feel like doing right now.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Enabling Checksums
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Bug in tm2timestamp