SRFI 19 bug regarding `time-difference`
Bug #426569 reported by
Andreas Rottmann
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))
(time=? posix-epoch
To post a comment you must log in.
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.