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

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.