timecop Timecop does not handle DateTime nanoseconds properly

trafficstars

I don't think this is the same issue as #70 but forgive me if this is a duplicate.

It appears that Timecop does not preserve nanoseconds in DateTime, so subsequent comparisons with DateTime.now fail.

Context: Mac OS X 10.6.8, Ruby 1.9.3p362, Timecop 0.5.9.2

Given this file:

require 'spec_helper'
describe Timecop do
  it 'verifies that now is now' do
    now = DateTime.now
    begin
      Timecop.freeze(now)
      DateTime.now.should == now
    ensure
      Timecop.return
    end
  end
end

I get the results:

Failures:

  1) Timecop verifies that now is now
     Failure/Error: DateTime.now.should == now
       expected: #<DateTime: 2013-03-04T08:21:49-08:00 ((2456356j,58909s,535056000n),-28800s,2299161j)>
            got: #<DateTime: 2013-03-04T08:21:49-08:00 ((2456356j,58909s,0n),-28800s,2299161j)> (using ==)
       Diff:
       @@ -1,2 +1,2 @@
       -#<DateTime: 2013-03-04T08:21:49-08:00 ((2456356j,58909s,535056000n),-28800s,2299161j)>
       +#<DateTime: 2013-03-04T08:21:49-08:00 ((2456356j,58909s,0n),-28800s,2299161j)>
     # ./spec/models/timecop_spec.rb:7:in `block (2 levels) in <top (required)>'

Mar 04 '13 16:03 rdpoor

#70 should fix this as well.

Mar 04 '13 22:03 stopdropandrew

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.

Mar 04 '13 22:03 rdpoor

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'

Mar 04 '13 23:03 stopdropandrew

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

Mar 05 '13 00:03 rdpoor

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.

Mar 05 '13 20:03 stopdropandrew

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.

Mar 09 '13 13:03 rdpoor

#89 should also resolve this.

Jun 04 '13 21:06 yaauie

This should be fixed in 0.6.2 which I just pushed.

Jul 14 '13 19:07 travisjeffery

:heart:

Jul 14 '13 19:07 yaauie

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.

Jul 14 '13 19:07 travisjeffery

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.)

Jul 16 '13 00:07 rdpoor

timecop timecop copied to clipboard

Timecop does not handle DateTime nanoseconds properly

timecop
timecop copied to clipboard