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 по дате отправления:

Предыдущее
От: Tulassay Zsolt
Дата:
Сообщение: timespan problem
Следующее
От: lyman1@mindspring.com
Дата:
Сообщение: unsubscribe