Dear Tom, dear Kevin In fact "show integer_datetimes;" returns "off". As such there is a perfect reason for this rounding. I assumed wrongly this being a bug. Sorry :-)
I understand as well your arguments on why not to use such a value for infinity. The reason why I used it was because I ported this data from a mainframe DB2 database where this value by tradition represented a high value and NULL values not being used for compatibility in regards to the mapped data type in PL1 and pure text-file processing of the same data. In these programs the length of the year part of a timestamp is limited to 4 digits. This is where I noted the rounding which had occurred as a result of my data imports into Postgresql. Thanks again for your information and sorry for the disturbance :-) Regards, Matthias On Fri, Jul 31, 2009 at 11:00 PM, Kevin Grittner < kevin.gritt...@wicourts.gov> wrote: > "Matthias" <matthias.ce...@gmail.com> wrote: > > > I noticed an unusual (and from my point of view inconsistent) > > rounding of a timestamp: > > What do you get when you run?: > > show integer_datetimes; > > If it is off, which is probably the default for your distribution > under 8.3.X, timestamps are floating point (approximate) values which > get less precise as you move away from the base timestamp of > '2000-01-01 00:00'. > > The default under 8.4 is to use integer timestamps, which have a > microsecond precision across the range they support. (That range is > not as broad as the floating point format, but plenty large for most > practical uses.) > > You can configure PostgreSQL to use integer timestamps in 8.3 if you > build from source, but you will need to convert your database. > > -Kevin >
