On Wed, 2011-10-05 at 13:31 +0100, Caolán McNamara wrote:
I pushed my patch, mostly because its the simplest, and Lionel can
double-check it later at his leisure.
I agree.
(*) Both patches discard milliseconds. I *guess* this is
the right thing to do, but would welcome others'
opinions. Anyway, there is no more need for the TODO
comment saying to ask this question.
We're kind of stuck there without a lot of work because 100ths of a
second is as good as our existing timestamps support. Probably ok given
given http://support.microsoft.com/kb/263872
<aside>
Heh. The microsoft page warns me "This article applies to
a different operating system than the one you are
using. Article content that may not be relevant to you is
disabled." Take that, you lefties who care about
cross-platform development!
For comparison, I tried inserting a value with too much
precision into a TIMESTAMP(4) field in PostgreSQL. The
result was silent truncation, at least as far as I can see
by selecting the field in psql.
</aside>
Actually, I was questioning the decision to truncate
milliseconds rather than rounding to the nearest hundredth.
It common (but not overwhelmingly common) to round values
when a conversion loses precision, but truncation is
consistent with the common treatment of times outside
programming. I guess I just answered my question: when
programming and the outside world bump into each other, the
real world should win.
Thanks,
Terry.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.