Hello, I have a test that looks like:
Timecop.travel(some_date)
company = create_company
[…]
Timecop.freeze
EmailPolicy::Actions::Block(company)
expect(Preferences::EmailRateLimit.for(company).blocked_until).to eq(6.hours.from_now)
Where EmailPolicy::Actions::Block calls Time.now, and serialised the date to interact with other systems, and Preferences::EmailRateLimit deserialised the date. Times are serialised down to the nanosecond.
It failed with:
Failure/Error: expect(Preferences::EmailRateLimit.for(company).blocked_until).to eq(6.hours.from_now)
expected: 2024-05-14 19:42:47.696001634 +0000
got: 2024-05-14 19:42:47.696001634 +0000
Which baffled me a bit, since I didn't consider that the Time used to calculate 6.hours.from_now would have a fraction of a nanosecond difference to the deserialised Time from the Preferences system.
Previously, the test only had the Timecop.freeze line & worked great. It was only after adding the Timecop.travel that the two identical-looking Times started comparing as unequal. So that made me look at how the travel_offset was added to create the Time.now used for Timecop.freeze, and I saw it was a Float 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 Times returned under Timecop.travel may sometimes have more precision than you might expect, and shouldn't be compared to Times created from other sources.
Hello, I have a test that looks like:
Where
EmailPolicy::Actions::BlockcallsTime.now, and serialised the date to interact with other systems, andPreferences::EmailRateLimitdeserialised the date. Times are serialised down to the nanosecond.It failed with:
Which baffled me a bit, since I didn't consider that the
Timeused to calculate6.hours.from_nowwould have a fraction of a nanosecond difference to the deserialisedTimefrom thePreferencessystem.Previously, the test only had the
Timecop.freezeline & worked great. It was only after adding theTimecop.travelthat the two identical-lookingTimes started comparing as unequal. So that made me look at how thetravel_offsetwas added to create theTime.nowused forTimecop.freeze, and I saw it was aFloatwith 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
Times returned underTimecop.travelmay sometimes have more precision than you might expect, and shouldn't be compared toTimes created from other sources.