Any specs that use Timecop fail

[vledniov]

The problem is that inside the lib itself, you use Time.now.
If you have a spec inside the system, where you have to freeze the time, already the locking mechanism is not working, as it will always try lock with the same timestamp.

now variable you use in lock, try_lock and extend methods, will always be the same.

Can you handle time-freezing situations, as it is pretty critical for some use cases.

[kareemk]

Could you share some code? I don't fully understand the problem you're facing but I'd like to fix it.

[vledniov]

https://github.com/travisjeffery/timecop - here is the gem
Yup, of course !!

before do
  Timecop.freeze(Time.local(2014, 01, 01))
end

after do
  Timecop.return
end

it "does something" do
  # Here I acquire the lock, and enter the critical section
  # because of timecop (necessary to log some time entries), inside the gem
  # where you call Time.now.to_i, I will always receive the UNIX timestamp for 1st January 2014 :(
end

[kareemk]

Ok, got it. So you would like to be able to change the time of the lock? What would be the ideal change to the API/behavior?

[vledniov]

It would be excelent if you could ignore the Timecop gem.

An idea would be to get the current time directly from Lua, so the Time freezing gem in Rails will not affect it anyhow.

What do you think about that ?

[kareemk]

You can't get the current time in LUA because it isn't deterministic (see http://redis.io/commands/EVAL).

So there really isn't a way to ignore timecop without refactoring your test i'm afraid.

[vledniov]

I see...
Okay, you can close the issue then

[kareemk]

Sorry about that @vledniov.

Would adding a now method to the lock that you could stub help?

[vledniov]

Yup, it will help a lot in handling specs