Daylight Savings Time issue? about timecop HOT 4 CLOSED

10.days does not actually produce a Fixnum as it appears to; instead it returns a ActiveSupport::Duration object that masquerades as a Fixnum. From Timecop's perspective, the argument appears to be a Fixnum, so it adds it to Time.now,as it would any other Fixnum; what actually happens is dependent on ActiveSupport's monkey-patching of the Time class, and how it handles durations in a smart-but-darkly-magic maner.

1.9.3 :001 > (10.days).class
 => Fixnum
1.9.3 :002 > # lies.
1.9.3 :003 > Marshal.dump( 10.days )
 => "\004\bo:\034ActiveSupport::Duration\a:\v@valuei\003\000/\r:\v@parts[\006[\a:\tdaysi\017"

from timecop.

@yaauie @levity's issue is independent from the AS support since that was pushed in the time since he made the issue.

from timecop.

The argument is caught here, well before we get to the new ActiveSupport support, because the argument masquerades as a Fixnum.

Since AS monkey-patches Time#+ to handle ActiveSupport::Duration as an argument, the behavior above is the expected behavior; his 10.days did span his local DST change (note he's not working in utc, merely displaying the result in utc), and the result reflects that.

from timecop.

Thanks for the explanation, @yaauie. So AS is intentionally advancing one less hour, so that the time in my local time zone will appear to be exactly 10 days ahead. It makes sense to me now.

from timecop.