Open dgholz opened 3 months ago
Time
s returned underTimecop.travel
may sometimes have more precision than you might expect, and shouldn't be compared toTime
s created from other sources.
I opened #421 as a possible approach to removing this caveat, though I do worry that the test doesn't cover the case when Timecop.travel
is called with a Time
created with fractions of a nanosecond.
Nice, just stumbled over this today.
the test doesn't cover the case when
Timecop.travel
is called with aTime
created with fractions of a nanosecond
Resolved, I added a test explicitly for this.
Reopening this issue since i had to revert the PR
Hello, I have a test that looks like:
Where
EmailPolicy::Actions::Block
callsTime.now
, and serialised the date to interact with other systems, andPreferences::EmailRateLimit
deserialised the date. Times are serialised down to the nanosecond.It failed with:
Which baffled me a bit, since I didn't consider that the
Time
used to calculate6.hours.from_now
would have a fraction of a nanosecond difference to the deserialisedTime
from thePreferences
system.Previously, the test only had the
Timecop.freeze
line & worked great. It was only after adding theTimecop.travel
that the two identical-lookingTime
s started comparing as unequal. So that made me look at how thetravel_offset
was added to create theTime.now
used forTimecop.freeze
, and I saw it was aFloat
with a much higher precision than was possible with a computer clock.I have some ideas on how to change my test to pass, but thought I'd raise this issue to highlight that the
Time
s returned underTimecop.travel
may sometimes have more precision than you might expect, and shouldn't be compared toTime
s created from other sources.