double rounding in xtime_diff()?

[Markus Kuhn]

Paul Eggert wrote on 1998-10-12 06:21 UTC:
>    Date: Sun, 11 Oct 1998 12:22:03 +0100
>    From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
> 
>      (double) ((t1.sec - t2.sec) + (t1.nsec - t2.nsec) / 1.0e9)
> 
>    where t?.sec is at least 64-bit int and t?.nsec is at least 32-bit int.
> 
>    Can you really construct input values that will lead to your claimed
>    double rounding error
> 
> Sure.  Let's use the Sparc IEEE implementation, which
> straightforwardly maps `double' to IEEE 64-bit double, and let's
> assume round-to-even, which is the IEEE default.  Then here are
> example input values:
> 
> t1.sec = 9007199254740993 (i.e. 2**53 + 1)
> t1.nsec = 1000000000 (i.e. 10**9)
> t2.sec = t2.nsec = 0
> 
> The exact answer is 9007199254740994 (i.e. 2**53 + 2), a number that
> is exactly representable as an IEEE double.  But the expression above
> yields 9007199254740992 (i.e. 2**53) -- it is off by 2.

Come on, that is a value 0.28 billion years from now. Do you have a
non-pathologic case, where you do not fill up the double mantissa
completely? We define non-pathological as follows:

Clive Feather was just here in the Lab, and one of the things he said
certainly needs to be changed is that the struct xtime requirement

  int_fast64_t sec;
  int_fast32_t nsec;

has to be relaxed to require sec only to represent roughly all values
from the start of the year -9999 to the end of the year +9999
("proleptic Gregorian calendar in astronomical integer year notation"
for the nitpickers ;-). This includes all ISO 8601 representable time
stamps, the Julian Date origin, the limits of the accuracy of the
Gregorian calendar, the entire recorded human history ("recorded"
meaning "written documents have been found"), and should therefore be OK
for >>99% of all applications. This range requires a bit less than 40
bits for sec, and then we do not care about rounding errors in IEEE
double if sec is not a 40-bit representable integer.

A few other things Clive mentioned: The language of my draft is not
acceptable and needs a major rewrite to become an ISO proposal. It has
to be prefixed with a convincing and very easy to read tutorial with
some usage examples (which will later become part of the rationale) that
introduces readers to concepts and problem areas such as leap seconds
and time zones and clearly motivates every proposed feature (whereas my
text at the moment was more written for people with a long experience in
the field and gives just pointers into the literature).

The *real* problems are more related to how we present the new proposal
to the committee and actually getting it through, and not so much to all
the more bizarre technical things we have been discussing here over the
past few days. In other words, we should be much more concerned about
the PR aspects of the proposal than about very technical details and
esoteric clock models, otherwise this will stay an academic exercise.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>