From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in tm2timestamp |
Date: | 2013-03-04 19:54:45 |
Message-ID: | 13199.1362426885@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-03-04 20:08:26 | Re: Bug in tm2timestamp |
Previous Message | Jeff Davis | 2013-03-04 19:54:07 | Re: Enabling Checksums |