Replace item number 5 with the four items below.
5. An instance of RationalTime is always interpreted as an interval of time (just as is an instance of RelativeTime). The interval, identified as the subinterval in items 6-8 below, is given by (((millis/103)+(nanos/109))/frequency) seconds.
6. Methods or constructors use instances of RationalTime in one of two ways, as a single use or as a repetitive use (it is always clear from the context which use is appropriate). When used singly the interval is calculated as above but used as that value rounded down to the nearest expressible value. E.g., the RationalTime instance of value, (frequency = 3, interval = (1000 milliseconds, 0 nanoseconds)) used singly must be interpreted as an interval of length 333 milliseconds plus 333,333 nanoseconds, which is 333,333,333 nanoseconds. (The nearest expressible value is with respect to the fields in the class RationalTime and the values expressible by their types as defined by The Java Language Specification).
7. A repetitive use of an instance of RationalTime first establishes a framing which is an implicit and infinite sequence of times separated by, exactly, the subinterval (((millis/103)+(nanos/109))/frequency) seconds starting at a given start time. Since the subinterval, by design, may not be exactly expressible the RTJS requires the following, less rigorous, guarantee; the method's or constructor's activity must occur exactly frequency times in each interval of length ((millis/103) + (nanos/109)) seconds even if the subintervals between occurrences of the activity must be of unequal lengths due to expressibility limitations. E.g., the RationalTime instance of value, (frequency = 3, interval = (1000 milliseconds, 0 nanoseconds)) used repetitively must be interpreted as an interval of length exactly 1/3 seconds, thus the framing times are, assuming a starting time of x, (x+1/3, x+2/3, x+3/3, x+4/3, ... ) . However the implementation is conformant if it causes the activity to occur at the end of each of the following times, (x+0.333333333, x+0.666666667, x+1.0, x+1.333333333, ...). The RTSJ does not impose any required distribution on the relationship of the lengths of the subintervals but strongly suggests that implementations attempt to make them of approximately equal lengths within expressibility limits.
8. The requirement of item 7 above must hold even given the presence of finite Clock precision, Clock jitter, and Clock cumulative inaccuracy. (Implementation note: Of the three above problems, precision and jitter can be known in all cases and cumulative inaccuracy can only be known for software clocks. However the RTSJ allows the implementation to assume that the associated hardware clock has no cumulative inaccuracies (because such a cumulative inaccuracy cannot be known except to compare the clock to an external timekeeping mechanism. But, such a comparison in itself suffers from relativistic problems and theory tells us it is impossible to do correctly to arbitrary precision). These three effects must be corrected in the repetitive use of an instance of RationalTime so that an imagined external timekeeping mechanism with exactly the same cumulative inaccuracy of the internal hardware clock and infinite precision will detect exactly frequency occurrences of the activity in each interval as defined above.