Re: Bug in tm2timestamp

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

In response to

Responses

Browse pgsql-hackers by date

  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