Re: round - timestamp bug
От | Thomas Lockhart |
---|---|
Тема | Re: round - timestamp bug |
Дата | |
Msg-id | 3A81707C.99219598@alumni.caltech.edu обсуждение исходный текст |
Ответ на | round - timestamp bug (Gonzalo Arana <garana@sinectis.com.ar>) |
Ответы |
Re: Re: round - timestamp bug
|
Список | 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 по дате отправления: