Re: BUG #2056: to_char no long takes time as input? - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #2056: to_char no long takes time as input?
Date
Msg-id 26860.1132780954@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #2056: to_char no long takes time as input?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: BUG #2056: to_char no long takes time as input?
Re: BUG #2056: to_char no long takes time as input?
List pgsql-bugs
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I see your issue with HH/HH24, but I wanted this to work:

>     test=> select to_char('14 hours'::interval, 'HH');
>      to_char
>     ---------
>      14
>     (1 row)

> With the HH/HH24 change that is going to return 2.  Do interval folks
> know they would have to use HH24 for intervals?

Dunno if they know it, but they always had to do it that way before 8.1,
so it's not a change to require it.  I get this in everything back to
7.2:

regression=# select to_char('14 hours'::interval, 'HH');
 to_char
---------
 02
(1 row)

regression=# select to_char('14 hours'::interval, 'HH24');
 to_char
---------
 14
(1 row)

and I don't see anything especially wrong with that behavior, as long as
it's documented.

> Should we subtract 12 only if the time is < 24.  That also seems
> strange.  Also, a zero hour interval to HH would return 12, not 0.

Offhand I'd vote for making the HH code use a "mod 12" calculation,
and making AM/PM depend on the value "mod 24".  This gives at least a
slightly sane behavior for intervals > 24 hours.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #2056: to_char no long takes time as input?
Next
From: Alvaro Herrera
Date:
Subject: Re: strange disappearence of postgres file