Re: Bug in tm2timestamp
От | Magnus Hagander |
---|---|
Тема | Re: Bug in tm2timestamp |
Дата | |
Msg-id | CABUevEyGZ=PpC_MngRJd+H988Ox01=QjQ5gzqTP+VtOAP=So8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Bug in tm2timestamp (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: