Re: Timestamp/Interval proposals: Part 2 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Timestamp/Interval proposals: Part 2
Date
Msg-id 1023792761.6942.59.camel@taru.tm.ee
Whole thread Raw
In response to Re: Timestamp/Interval proposals: Part 2  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
On Tue, 2002-06-11 at 11:31, Karel Zak wrote:
> On Tue, Jun 11, 2002 at 12:37:09PM +0400, Fduch the Pravking wrote:
>  
> > And 'DD' is defined as in range 1..31...
> > What if I try to select '100 days'?
> > 
> > fduch=> SELECT to_char('100days'::interval, 'YYYY-MM-DD HH24:MI:SS');
> >        to_char
> > ---------------------
> >  0000-00-10 00:00:00
> 
>  I already said it. The to_char() is 'tm' struct interpreter and use
>  standard internal PG routines for interval to 'tm' conversion.

The point is it should _not_ do that for interval. 

It does not convert to 'tm' for other types:

hannu=# select to_char(3.1415927,'0009D9');to_char 
--------- 0003.1
(1 row)

also, afaik there is no conversion of interval to datetime in
postgresql:

hannu=# select '25mon37d1s'::interval::timestamp;
ERROR:  Cannot cast type 'interval' to 'timestamp with time zone'

> We can
>  talk about why 100days is converted to '10' days and months aren't
>  used. I agree this example seems strange. Thomas?

You can't convert days to months as there is no universal month length.

this is the current (correct) behaviour:

hannu=# select '25mon37d1s'::interval;           interval            
--------------------------------2 years 1 mon 37 days 00:00:01
(1 row)


------------------
Hannu



pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: Project scheduling issues (was Re: Per tuple overhead,
Next
From: Bruce Momjian
Date:
Subject: Re: Project scheduling issues (was Re: Per tuple overhead,