From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nick Addington <adding(at)math(dot)wisc(dot)edu>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2056: to_char no long takes time as input? |
Date: | 2005-12-03 16:46:11 |
Message-ID: | 200512031646.jB3GkC223841@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
Patch applied to HEAD and 8.1.X.
---------------------------------------------------------------------------
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-03 17:08:42 | Re: BUG #2091: ecpglib.h needs to be updated.... |
Previous Message | Bruce Momjian | 2005-12-03 16:39:41 | Re: BUG #2091: ecpglib.h needs to be updated.... |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-12-03 17:00:32 | Re: [HACKERS] snprintf() argument reordering not working under Windows |
Previous Message | Tom Lane | 2005-12-03 16:43:00 | Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508 digits |