From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | lockhart(at)fourpalms(dot)org |
Cc: | William Boyle <woboyle(at)ieee(dot)org>, garana(at)sinectis(dot)com, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Re: round - timestamp bug |
Date: | 2001-02-07 16:10:53 |
Message-ID: | 28480.981562253@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> The original report did not give complete platform details, but in
> my recollection the *only* recent cases of this display problem come
> from Mandrake systems which are built with overly aggressive compiler
> optimization options.
No, the behavior is not platform-specific. I'm on HP-PA:
regression=# select 'Tue 23 Jan 21:38:59.997 2001'::timestamp;
?column?
---------------------------
2001-01-23 21:38:60.00-05
(1 row)
The problem is that we round the fractional seconds part to two digits
only after we've separated seconds from the other fields. (I imagine
the code is not even doing that explicitly, but leaving it to sprintf
to do so.) It would work better if we rounded the entire floating
timestamp value to two fractional digits before we break it down,
eg with
tstamp = rint(tstamp * 100.0) / 100.0;
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jered Floyd | 2001-02-07 16:18:40 | Re: byteain() doesn't parse correctly |
Previous Message | Thomas Lockhart | 2001-02-07 15:57:48 | Re: round - timestamp bug |