SRFI 19 bug regarding `time-difference`

Bug #426569 reported by Andreas Rottmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Scheme Libraries
Fix Released
High
Derick Eddington

Bug Description

`time-difference` yields incorrect results when asked to produce a
time-duration with a negative nanosecond value. The attached patch
adds a testcase and proposed fix.

I at first was not sure about whether this is a bug at all, as the
SRFI document doesn't talk about negative durations, but
looking at the test cases, and the fact the following code yields #f,
I'm pretty confident.

  (let* ((posix-epoch (date->time-utc (make-date 0 0 0 0 1 1 1970 0)))
         (a-bit (make-time time-duration 5000 0))
         (a-bit-later (add-duration posix-epoch a-bit)))
    (time=? posix-epoch
            (add-duration a-bit-later (time-difference posix-epoch a-bit-later))))

Revision history for this message
Andreas Rottmann (rotty) wrote :
Revision history for this message
Derick Eddington (derick-eddington) wrote :

Yeah, the tests make me sure it's intended to support negative durations. The tests never using negative nanoseconds and that abs make me wonder if the author was thinking to make it like R6RS div-and-mod but forgot to adjust the quotient part. tm:nanoseconds->values is obviously giving incorrect results because they don't equal the input value. I'm going to fix it by using div-and-mod to keep the nanoseconds field non-negative, as that abs suggests might have been the intent, just in case somewhere else assumes the nanoseconds field is non-negative. Thanks for the new tests and for reporting this.

Changed in scheme-libraries:
assignee: nobody → Derick Eddington (derick-eddington)
importance: Undecided → Critical
status: New → In Progress
Revision history for this message
Derick Eddington (derick-eddington) wrote :

Fixed in revision 88.

Changed in scheme-libraries:
status: In Progress → Fix Released
importance: Critical → High
Revision history for this message
Derick Eddington (derick-eddington) wrote :

I reviewed the srfi-19.scm reference implementation again, and I'm now sure that the nanoseconds field must be non-negative. tm:add-duration and tm:subtract-duration make sure to keep it non-negative, and time=?, time<?, etc. won't be correct if both negative and non-negative were allowed (because although times would be logically equal their fields won't).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.