Обсуждение: Re: Problem migrating dump to latest CVS snapshot.

(moved to -hackers, since I don't have posting privileges on -general)

> I've suggested before that timestamp output should round the timestamp
> value to two fractional digits *before* breaking it down into year/
> month/etc.  Seems like this is a perfect example of the necessity
> for that.  Thomas, what say you?

Well, that is a good idea to solve the "hidden digits problem",
introducing instead a new "lost digits feature". But I've been hoping to
hear a suggestion on how to allow a variable number of digits, without
cluttering things up with output values ending up with a bunch of 9's at
the end.

When I first implemented the non-Unix-time date/time types, I was
worried that the floating point math libraries on *some* of the two
dozen platforms we support would tend to print out .9999... values
(having seen this behavior *way* too often on older Unix boxes). But
I've never actually asked folks to run tests, since I was just happy
that the floating point implementation worked well enough to go into
production.

Thoughts?
                     - Thomas

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> I've suggested before that timestamp output should round the timestamp
>> value to two fractional digits *before* breaking it down into year/
>> month/etc.  Seems like this is a perfect example of the necessity
>> for that.  Thomas, what say you?

> Well, that is a good idea to solve the "hidden digits problem",
> introducing instead a new "lost digits feature".

We already have the "lost digits feature", since you cannot get
timestamp_out to display anything after the second digit.  Now,
if you want to improve on that ...

> But I've been hoping to
> hear a suggestion on how to allow a variable number of digits, without
> cluttering things up with output values ending up with a bunch of 9's at
> the end.

Well, we could print the seconds part with, say, %.6f format and then
manually delete trailing zeroes (and the trailing dot if we find all the
fractional digits are zero, which would be a nice improvement anyway).
I'd still think it a good idea to round to the intended number of digits
before we break down the date, however.

The real question here is how far away from the Epoch do you wish to
produce reasonable display of fractional seconds?  We have 6-digit
accuracy out to around 200 years before and after Y2K, which is probably
far enough, though maybe we should make it 5 digits to allow some
more margin for error.
        regards, tom lane