Re: Bug in tm2timestamp - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in tm2timestamp
Date
Msg-id 13199.1362426885@sss.pgh.pa.us
Whole thread Raw
In response to Bug in tm2timestamp  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Bug in tm2timestamp  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Bug in tm2timestamp  (Magnus Hagander <magnus@hagander.net>)
List 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 by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Enabling Checksums
Next
From: Alvaro Herrera
Date:
Subject: Re: Bug in tm2timestamp