Timecop Time and Database Time

June 8, 2014

Timecop is a great addition to your testing toolbox, but if you’ve ever tried to use Timecop to interact with a database, and then got the most mysterious of existential errors:

expected: Sun, 08 Jun 2014 19:18:22 UTC +00:00
     got: Sun, 08 Jun 2014 19:18:22 UTC +00:00

I feel your pain.

Stop—Overtaken by Events

Timecop used to be the go-to for this in a Rails application, but Rails has had its own time travel tools since 4.1. It even has matchers that handle this particular pain point. You should consider using the built-in tools before adding another gem to your project.

Rails documentation: https://api.rubyonrails.org/classes/ActiveSupport/Testing/TimeHelpers.html

Using it in RSpec: https://andycroll.com/ruby/replace-timecop-with-rails-time-helpers-in-rspec/

—

The trouble comes from the fact that Timecop is freezing time at the resolution of the native Time class, which on my Mac OS X machine is microseconds (aka “usec”), but the database, in this case MySQL only records time to the second. RSpec is trying to be helpful with its matchers by calling <code>#to_s`, but that hides the significant, sub-second difference.

Here’s a quick little monkey patch that I added to my spec support:

class Timecop
  def self.database_compatible_time(now = Time.zone.now)
    now.change(usec: 0)
  end
end

This uses a Rails helper to reset the microsecond portion of the time object. So, instead of

now = Time.zone.now

Timecop.freeze(now) do
  ...
end

I do this:

now = Timecop.database_compatible_time

Timecop.freeze(now) do
  ...
end

And no more head scratching. It’s sort of database specific, so your mileage may vary.