On Mon, Mar 4, 2013 at 8:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
That's pretty much what I thought - thanks for confirming, and for
putting the fix in!
> 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.
Yeah, and it wouldn't be a good backpatchable thing anyway...
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/