Timecop does not handle DateTime nanoseconds properly about timecop HOT 11 CLOSED

#70 should fix this as well.

from timecop.

Cool. Forgive me for a naive request: can you give me a pointer on how to incorporate your pull request into my git environment so I can test it? (Y'know, trust but verify and all that! :). I'm asking partly because the I'm not using ActiveSupport (specifically, Timecopy.active_support => nil), and it's not clear how the #to_r problem affects my case.

from timecop.

I take it back, I didn't fix DateTime. I can write a patch for that sometime tomorrow and include it here. As far as trying out my branch, you can, in your Gemfile, change:

gem 'timecop'

to

gem 'timecop', :git => 'https://github.com/stopdropandrew/timecop', :branch => 'nanosecond_fix'

from timecop.

Grazie. I'll wait until you've included a DateTime patch and then test out your gem branch.

from timecop.

I took a quick stab at it with no luck. Time/DateTime conversion is too much of a pain in the ass. I typically try to avoid using DateTime whenever possible. Sorry I couldn't help more.

from timecop.

A viable workaround that doesn't require any patching is to pre-truncate the time you pass to Timecop.freeze(), as in:

now_ = DateTIme.now
now = DateTime.new(now_.year, now_.month, now_.day, now_.hour, now_.minute, now_.second)
Timecop.freeze(now)

Not really pretty, but it works.

from timecop.

#89 should also resolve this.

from timecop.

This should be fixed in 0.6.2 which I just pushed.

from timecop.

❤️

from timecop.

Actually hold on, I thought this the same issue as another issue I just fixed but I'm actually testing it now (btw, it'd be helpful if you posted test cases in Test::Unit and even better if you made PRs with them) and it appears it didn't fix this.

from timecop.

btw, it'd be helpful if you posted test cases in Test::Unit

Done. See associated pull request. (Note: this is my first pull request -- I trust I followed protocol correctly.)

from timecop.