Re: [SQL] timespan problem - Mailing list pgsql-sql

From Tom Lane
Subject Re: [SQL] timespan problem
Date
Msg-id 20530.946771110@sss.pgh.pa.us
Whole thread Raw
In response to timespan problem  (Tulassay Zsolt <zsolt@tek.bke.hu>)
List 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 by date:

Previous
From: Tulassay Zsolt
Date:
Subject: timespan problem
Next
From: lyman1@mindspring.com
Date:
Subject: unsubscribe