Strange DST issue about timecop HOT 6 CLOSED

I added

def test_issue_51
# During DST:
Timecop.travel(2012,11,2) do
  Timecop.freeze(DateTime.new(2012,1,1,10,0,0)) do
    p Time.now.to_s
  end
end
# => "2012-01-01 06:00:00 -0500"

# After DST:
Timecop.travel(2012,11,5) do
  Timecop.freeze(DateTime.new(2012,1,1,10,0,0)) do
    p Time.now.to_s
  end
end
#=> "2012-01-01 05:00:00 -0500"
  end

to test/timecop_test.rb but I can't reproduce this:

➜  timecop git:(master) ✗ date
Tue Oct  2 11:57:21 CDT 2012
➜  timecop git:(master) ✗ rake 
...
"2012-01-01 05:00:00 -0500"
"2012-01-01 05:00:00 -0500"
...

➜  timecop git:(master) ✗ date 
Sun Dec  2 11:51:37 CST 2012
➜  timecop git:(master) ✗ rake 
...
"2012-01-01 05:00:00 -0500"
"2012-01-01 05:00:00 -0500"
...

Maybe we have different gems:

PATH
  remote: .
  specs:
    timecop (0.5.4)

GEM
  remote: https://rubygems.org/
  specs:
    active_support (3.0.0)
      activesupport (= 3.0.0)
    activesupport (3.0.0)
    coderay (1.0.8)
    git (1.2.5)
    jeweler (1.8.4)
      bundler (~> 1.0)
      git (>= 1.2.5)
      rake
      rdoc
    json (1.7.5)
    metaclass (0.0.1)
    method_source (0.8.1)
    mocha (0.13.0)
      metaclass (~> 0.0.1)
    pry (0.9.10)
      coderay (~> 1.0.5)
      method_source (~> 0.8)
      slop (~> 3.3.1)
    rake (10.0.2)
    rdoc (3.12)
      json (~> 1.4)
    slop (3.3.3)

PLATFORMS
  ruby

DEPENDENCIES
  active_support
  jeweler
  mocha
  pry
  rake
  timecop!

from timecop.

We found a similar DST issue this week. Some of our tests rely on a time (for example 2013-1-1 23:59 EST) to test certain actions on specific days. With the change to DST, TimeCop now takes that same string and adds an hour (Effectively making it 2013-01-02 00:59) which makes our tests fail.

from timecop.

An Example from the console:

1.9.3p327 :009 > time = DateTime.parse("2013-01-01 11:59pm EST")
 => Tue, 01 Jan 2013 23:59:00 -0500 

1.9.3p327 :010 > Timecop.freeze(time)
 => 2013-01-02 00:59:00 -0500 

1.9.3p327 :011 > time = DateTime.parse("2013-01-01 11:59pm EDT")
 => Tue, 01 Jan 2013 23:59:00 -0400 

1.9.3p327 :012 > Timecop.freeze(time)
 => 2013-01-01 22:59:00 -0500 

from timecop.

I'm getting this as well in a rails 3.2 application but can confirm it doesn't happen in TimeCop's repo. Must be something else outside of activesupport.

For now I just added an explicit Timecop.travel around the freeze to make sure it's a consistent date and that seems to work.

from timecop.

This problem just started for me with the arrival of British Summer Time. I found replacing DateTime.parse with Time.parse fixed the problems for me.

from timecop.

@christophermanning had the right idea...the only problem is that something else in the test suite isn't cleaning up after itself properly and covers up the bug. Rename the test so that it is the first one to run (try renaming it test_a_issue_51 or something) and you'll find that it does reproduce the bug. I'm not sure which other test in the suite isn't cleaning up after itself properly. After I wrote this test myself that exposed this issue:

  def test_datetime_to_time_for_dst_to_non_dst
    # Start at a time subject to DST
    Timecop.travel(2009, 4, 1, 0, 0, 0, -4*60*60) do

      # Then freeze, via DateTime, at a time not subject to DST
      t = DateTime.new(2009,01,01,0,0,0, "-0500")
      Timecop.freeze(t) do

        # Check the current time via DateTime.now--should be what we asked for
        assert_date_times_equal t, DateTime.now

        # Then check the current time via Time.now (not DateTime.now)
        assert_times_effectively_equal Time.new(2009, 1, 1, 0, 0, 0, -5*60*60), Time.now
      end
    end
  end

I nearly went insane trying to figure out what differentiated it from @christophermanning's test_issue_51 above. Turns out, nothing differentiated it but the name! If I rename mine to test_z_datetime_to_time_for_dst_to_non_dst, it passes.

from timecop.