Re: round - timestamp bug - Mailing list pgsql-bugs

From Thomas Lockhart
Subject Re: round - timestamp bug
Date
Msg-id 3A81707C.99219598@alumni.caltech.edu
Whole thread Raw
In response to round - timestamp bug  (Gonzalo Arana <garana@sinectis.com.ar>)
Responses Re: Re: round - timestamp bug  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
> > It seems that there is a problem when retrieving a timestamp value (rounding).
> > NO minute has 61 seconds.  Am I wrong?
> > radius=# select timestamp 'Tue 23 Jan 21:38:59.997 2001';
> > ---------------------------------
> >  Tue 23 Jan 21:38:60.00 2001 ART
> Actually, such leap-seconds are possible. This can happen when your
> timebase is a NTP time server such as the Naval Observatory, etc. They
> are used for micro adjustments to adjust clock to siderial (celestial)
> time. I have had to write date+time classes in C++ which could handle
> this exact situation... X-). The fact that Postgres-SQL can handle this
> is probably a good thing.

All true, but the underlying problem in this case is not that "59.997"
or even "60.0" is accepted, but that it is displayed as "60.0" (although
a value of "60" does show up during leap second transitions, it is only
as a placeholder while waiting for the next "official minute" to start
;). 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. Check and verify that you are not using "-O n" and
"-fast-math" together when compiling PostgreSQL.

As an aside, the Mandrake folks are aware of this problem in their
distro and have recently fixed their version of the spec file; hopefully
we will get this folded back into Lamar's spec file before 7.1 goes out.

                    - Thomas

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: round - timestamp bug
Next
From: Tom Lane
Date:
Subject: Re: Re: round - timestamp bug