Horton

Thread

  1. Bugs in to_char function

    Tom Rogers <trogers3@creigh.com> — 2000-10-17T14:47:40Z

    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

  2. Re: Bugs in to_char function

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-18T03:40:44Z

    "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

  3. Re: Bugs in to_char function

    Karel Zak <zakkr@zf.jcu.cz> — 2000-10-18T08:21:32Z

    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...

  4. Re: Bugs in to_char function

    Karel Zak <zakkr@zf.jcu.cz> — 2000-10-18T09:07:42Z

    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

  5. 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Karel Zak <zakkr@zf.jcu.cz> — 2000-10-18T13:24:06Z

    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?

  6. Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-18T15:21:05Z

    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

  7. Re: Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Karel Zak <zakkr@zf.jcu.cz> — 2000-10-18T15:37:10Z

    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

  8. Re: Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-18T16:19:14Z

    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 19026

  9. Re: Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-10-18T16:55:19Z

    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

  10. Re: Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-18T16:56:44Z

    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 19026

  11. Re: Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-10-18T16:57:10Z

    Oh, 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 19026

  12. Re: Re: 7.0.3 to_char() (was: [BUGS] Bugs in to_char function)

    Karel Zak <zakkr@zf.jcu.cz> — 2000-10-19T05:30:59Z

    On 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
 

> > 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.