SmartLogic Logo (443) 451-3001

The SmartLogic Blog

SmartLogic is a web and mobile product development studio based in Baltimore. Contact us for help building your product or visit our website to learn more about what we do.

Timecop 0.2.0 Released: Freeze and Rebase Time in Ruby

December 24th, 2008 by

I just released version 0.2.0 of Timecop this evening (morning).

The primary feature added was the distinction between “freezing” and “rebasing” time. In 0.1.0, would actually freeze time. This is no longer the case. Rather, a time offset will be calculated, and a running clock is simulated by always offsetting the time returned by (and friends) by the original offset.

(Note that time can still be frozen with Timecop.freeze.)

To update a previous version:

<code>sudo gem update timecop</code>

To install for the first time:

<code>sudo gem install timecop</code>

The new feature set allows us to avoid the following common pitfalls that were present in 0.1.0.

  1. In rails, if you had set up a time mock in the development environment, then every time you invoked script/generate migration (and others), the generator would read your mocked instance of, and use that date for the migration name.
  2. Any benchmarking/timing code executed within the yielded block would always return times of 0 seconds. This was due to time being frozen.

The other major change to the API was the deprecating of Timecop.unset_all in favor or Timecop.return.

This update also vastly improves the rdoc, making the public API much more accessible. The Timecop class has particularly thorough documentation.

For a more complete description of the gem, please refer to the introductory blog post.

  • Scott Moe

    Updated this morning and some specs started failing. I changed travel to freeze in all my specs that use timecop and they passed again.

    That might be as intended but based on the information from this post I am thinking travel might not be working right, at least in my Debian Linux development environment.

    Either way it was a quick fix and considering all time I have saved using timecop for testing I am thrilled to have a great testing facility like this.

    Thanks for the good work.

  • John Trupiano

    Hey Scott,

    Thanks for the feedback. I’d doubt that your specific distro would have any effect whatsoever on whether or not the #travel function works as intended. I’m not doing anything fancy with the system clock (basically just mocking As a result, I’d expect everyone to experience the same problems you’re having. I’d really like to sort this out if an issue does indeed exist.

    You mentioned that some of your specs started failing….not all of them? Is there any common thread you can see across those that began to fail?

    If you’re willing (and have the time), is there a chance you could write a very simple failing test case? The most important thing would be to isolate the issue outside of the context of your application’s logic. Something as simple as…

    def test_doesnt_work_for_me
      past = Time.local(2008, 10, 1) do
        # assert that the difference between now and the value passed to #travel is less than a second
        # this is basically assuming that your system is fast enough to execute this call in under a second
        # adjust as you feel the need.
        assert ( - past).abs <= 1000

    This is actually very close to the types of tests I wrote for this gem to ensure that #travel worked properly.

    If you’re willing to pitch in a hand, we can continue this conversation via email or on github.

    Thanks for your help, and especially for the feedback!


John Trupiano co-founded SmartLogic with Yair Flicker in May 2005 and was co-president through 2011. Check out his GitHub Projects or follow @jtrupiano on Twitter.

John Trupiano's posts