Re: BUG #2056: to_char no long takes time as input?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #2056: to_char no long takes time as input?
Дата
Msg-id 26860.1132780954@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #2056: to_char no long takes time as input?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: BUG #2056: to_char no long takes time as input?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: BUG #2056: to_char no long takes time as input?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: BUG #2056: to_char no long takes time as input?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: strange disappearence of postgres file