Bugs in to_char function
I wanted to include the following in a select statement:
to_char(departtime, 'HH12:MI PM') as xdepart
This gives the correct meridian value for all AM times but incorrectly
returns an AM meridian for PM times between 12:00 PM and 1:50:59 PM. If I
create the formatted Hours using 'HH24', the displayed 24 hour clock time is
correct.
I am using PostgreSQL version 7.0.2 on a RedHat Linux 6.2.
This is not a super critical problem for me because in this application it's
actually more correct for me to be using the 24 hour clock anyway, but I
just thought you might want to know about it. I would like to know though,
whether this is legitimate and I hope I'm not trying to do this incorrectly.
Thank you
Tom Rogers
"Tom Rogers" <trogers3@creigh.com> writes:
[to_char] gives the correct meridian value for all AM times but incorrectly
returns an AM meridian for PM times between 12:00 PM and 1:50:59 PM.
I believe this is a known bug in the 7.0 implementation of to_char, and
is long since fixed in development sources. Karel Zak is the author of
to_char and would know for sure. Karel, does it make sense to
back-patch a quick fix for this into REL7_0_PATCHES for the upcoming
7.0.3 release? If so, could you provide a patch?
regards, tom lane
On Tue, 17 Oct 2000, Tom Rogers wrote:
I wanted to include the following in a select statement:
to_char(departtime, 'HH12:MI PM') as xdepart
Very old story and already fixed in the current CVS. Wait for
great 7.1 :-)
Karel
PS. has this list some archive? - it's really frequent report...
On Tue, 17 Oct 2000, Tom Lane wrote:
"Tom Rogers" <trogers3@creigh.com> writes:
[to_char] gives the correct meridian value for all AM times but incorrectly
returns an AM meridian for PM times between 12:00 PM and 1:50:59 PM.I believe this is a known bug in the 7.0 implementation of to_char, and
is long since fixed in development sources. Karel Zak is the author of
to_char and would know for sure. Karel, does it make sense to
back-patch a quick fix for this into REL7_0_PATCHES for the upcoming
7.0.3 release? If so, could you provide a patch?
I look at "cvs co -P -r REL7_0_PATCHES pgsql" and it's worry,
the differention between 7.0.3 and 7.1 is in the formatting.c 5Kb :-(
Well, I try prepare patch for 7.0.3 for AM/PM.
Karel
On Tue, 17 Oct 2000, Tom Lane wrote:
"Tom Rogers" <trogers3@creigh.com> writes:
[to_char] gives the correct meridian value for all AM times but incorrectly
returns an AM meridian for PM times between 12:00 PM and 1:50:59 PM.I believe this is a known bug in the 7.0 implementation of to_char, and
is long since fixed in development sources. Karel Zak is the author of
to_char and would know for sure. Karel, does it make sense to
back-patch a quick fix for this into REL7_0_PATCHES for the upcoming
7.0.3 release? If so, could you provide a patch?
Well, a quick fix is a quick fix. The patch for REL7_0_PATCHES is in the
attache. Note, it must be apply in src/backend/utils/adt, because it is not
created as --recursive.
Karel
PS. 7.1 contains more changes for to_char/to_timestamp, this fix PM/AM
only ....
test=# select to_char(t, 'HH24 hours = HH12 p.m.') from day;
to_char
--------------------
01 hours = 01 a.m.
02 hours = 02 a.m.
03 hours = 03 a.m.
04 hours = 04 a.m.
05 hours = 05 a.m.
06 hours = 06 a.m.
07 hours = 07 a.m.
08 hours = 08 a.m.
09 hours = 09 a.m.
10 hours = 10 a.m.
11 hours = 11 a.m.
12 hours = 12 p.m.
13 hours = 01 p.m.
14 hours = 02 p.m.
15 hours = 03 p.m.
16 hours = 04 p.m.
17 hours = 05 p.m.
18 hours = 06 p.m.
19 hours = 07 p.m.
20 hours = 08 p.m.
21 hours = 09 p.m.
22 hours = 10 p.m.
23 hours = 11 p.m.
00 hours = 12 a.m.
(24 rows)
Right?
Karel Zak <zakkr@zf.jcu.cz> writes:
PS. 7.1 contains more changes for to_char/to_timestamp, this fix PM/AM
only ....
Sounds good, but you forgot to attach the patch ...
regards, tom lane
On Wed, 18 Oct 2000, Tom Lane wrote:
Karel Zak <zakkr@zf.jcu.cz> writes:
PS. 7.1 contains more changes for to_char/to_timestamp, this fix PM/AM
only ....Sounds good, but you forgot to attach the patch ...
Is it a problem? :-)
Karel
Attachments:
Unfortunately, it does not apply cleanly to the current CVS tree, and I
can't figure out how to merge your changes. Current formatting.c
attached.
On Wed, 18 Oct 2000, Tom Lane wrote:
Karel Zak <zakkr@zf.jcu.cz> writes:
PS. 7.1 contains more changes for to_char/to_timestamp, this fix PM/AM
only ....Sounds good, but you forgot to attach the patch ...
Is it a problem? :-)
Karel
Content-Description:
[ application/x-gzip is not supported, skipping... ]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Attachments:
/pg/backend/utils/adt/formatting.ctext/plainDownload
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Unfortunately, it does not apply cleanly to the current CVS tree,
Wake up Bruce, this is not *for* current CVS, it's a backpatch for
REL7_0_PATCHES.
regards, tom lane
Oh, OK. I will go back to sleep now.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Unfortunately, it does not apply cleanly to the current CVS tree,
Wake up Bruce, this is not *for* current CVS, it's a backpatch for
REL7_0_PATCHES.regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Oh, I see now. That 7.0.3 in the subject line means 7.0.3.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Unfortunately, it does not apply cleanly to the current CVS tree,
Wake up Bruce, this is not *for* current CVS, it's a backpatch for
REL7_0_PATCHES.regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026On Wed, 18 Oct 2000, Bruce Momjian wrote:
Oh, I see now. That 7.0.3 in the subject line means 7.0.3.
Probably :-) Full story about this is in your INBOX too.
Thanks
Karel
Show quoted text
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Unfortunately, it does not apply cleanly to the current CVS tree,
Wake up Bruce, this is not *for* current CVS, it's a backpatch for
REL7_0_PATCHES.