Re: [SQL] timespan problem
От | Tom Lane |
---|---|
Тема | Re: [SQL] timespan problem |
Дата | |
Msg-id | 20530.946771110@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | timespan problem (Tulassay Zsolt <zsolt@tek.bke.hu>) |
Список | pgsql-sql |
Tulassay Zsolt <zsolt@tek.bke.hu> writes: > forum=> select datetime(now())+'74565 days'::timespan as ido; > ido > ------------------------ > Thu Jan 19 14:07:30 2068 > (1 row) > forum=> select datetime(now())+'74566 days'::timespan as ido; > ido > ---------------------------- > Tue Dec 15 08:39:21 1931 CET > (1 row) Of course, both of the above are drastically wrong, since 74575 days should be upwards of 200 years. The problem appears to be an internal overflow in timespan_in, since you can show wrong results just with: regression=> select '74565 days'::timespan; ?column? ------------------------------------- @ 24854 days 17 hours 31 mins 44 secs (1 row) regression=> select '74566 days'::timespan; ?column? ----------------------------------------- @ 24854 days 12 hours 56 mins 32 secs ago (1 row) Looking into it, the guilty party seems to be tm2timespan() which blithely assumes that it need not worry about overflow from its "time" field to its "month" field: span->month = ((tm->tm_year * 12) + tm->tm_mon); span->time = ((((((tm->tm_mday * 24) + tm->tm_hour) * 60) + tm->tm_min)* 60) + tm->tm_sec); span->time = JROUND(span->time + fsec); Thomas, you want to deal with this one? Or is this code all going away in 7.0 anyway? regards, tom lane
В списке pgsql-sql по дате отправления: