Timecop 0.2.0 Released: Freeze and Rebase Time in Ruby

December 24th, 2008 by John Trupiano

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, Timecop.travel 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 Time.now (and friends) by the original offset.

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

To update a previous version:

sudo gem update timecop

To install for the first time:

sudo gem install timecop

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

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 Time.now, and use that date for the migration name.
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.

This entry was posted on Wednesday, December 24th, 2008 at 2:14 am by John Trupiano. John co-founded SmartLogic Solutions with Yair Flicker in May 2005. He is very actively involved with the Ruby and Rails communities, as well as the Baltimore/DC tech and business communities. Check out his GitHub Projects or follow @jtrupiano on twitter.

Tags: jtrupiano, Ruby, rubygem, tatft, test, timecop

This post is filed under John Trupiano, Ruby, TATFT, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Timecop 0.2.0 Released: Freeze and Rebase Time in Ruby”

Scott Moe says:

December 26, 2008 at 11:58 am

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 says:

December 26, 2008 at 1:12 pm

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 Time.now). 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)
  Timecop.travel(past) 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 (Time.now - past).abs <= 1000
  end
end
```
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

SmartLogic Solutions Blog