Closed dgholz closed 3 weeks ago
@joshuacronemeyer I'd greatly appreciate your opinion on this PR, if you have the time.
@joshuacronemeyer I still think this change has a significant benefit to users & would appreciate your opinions on it
@dgholz thank you for your detailed issue and for this PR. I was spaced out i guess when this came in, so thanks for bringing it to my attention. I will try to look at this soon.
Looks good!
@dgholz I reverted this because of a failing test.
1) Failure:
TestTimeStackItem#test_travel_offset_aligns_to_travel_time [test/time_stack_item_test.rb:314]:
travel offset precision (4503599627370496000000000) does not align with travel time precision (900719925474099200000000).
Expected: 0
Actual: 900719925474099200000000
Happy to look at it again.
Subtracting two
Time
s returns aFloat
, which may not be accurate down to subsecond resolution. BecauseFloat
s are stored as double-precision values (IEEE 754), they can have resolutions much higher than the typical minimum clock precision of 10e-9 seconds. Which can result in twoTime
object not comparing as equal when they are the same down to the nanosecond, when one has had atravel_offset
applied to it.To fix #420.