<html>
    <head>
      <base href="https://bugs.documentfoundation.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - Regression: Incompatible changes in date/time arithmetic introduced between Version: 6.0.4.2 (x64) and version 6.2.6.2 (ubuntu)"
   href="https://bugs.documentfoundation.org/show_bug.cgi?id=127334#c8">Comment # 8</a>
              on <a class="bz_bug_link 
          bz_status_UNCONFIRMED "
   title="UNCONFIRMED - Regression: Incompatible changes in date/time arithmetic introduced between Version: 6.0.4.2 (x64) and version 6.2.6.2 (ubuntu)"
   href="https://bugs.documentfoundation.org/show_bug.cgi?id=127334">bug 127334</a>
              from <span class="vcard"><a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> <span class="fn">Mike Kaganski</span></a>
</span></b>
        <pre>I suppose that some kind of rounding is required to accompany the change of
MINUTE etc. to wall clock, and changes like in <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - Rounding of durations displayed as wall clock time."
   href="show_bug.cgi?id=125099">bug 125099</a>. Since those changes
are targeted at correctness, but operate on inherently imprecise doubles, the
rounding would define the limit of the precision.

Excel, while also operating on doubles, and naturally accumulating errors at
operations on times, hides that by using rounding. Interestingly, it uses two
different rounding modes: one for cell formatting with fractions of second, and
another for HOUR/MINUTE/SECOND and cell formatting without fractions of second.
Rounding happens in both cases, but in first case it's to 1/1000 of a second,
and in second case (pun not intended) to 1 second.

Given that in our current range of datetimes, the arithmetic precision of + and
- is inside 1/100000 s, whole-seconds precision gives large margin - it would
need at least tens of thousands +- operations for the error to surface. For the
millisecond precision, the margin is also significant.

Possibly implementing the two different modes trying to mimic Excel is not
necessary, but limiting ourselves to ms seems correct, or else seeming
correctness of wall clock hits with issues like this one.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>