Time.freeze(Integer) does not behave as expected

[margaretdax]

Intuitively I would expect Time.freeze(12345) to freeze time at 12345 seconds from the epoch, not Time.now + 12345 seconds.

I feel like this behavior should either be changed to an error case or to freeze the time to Time.at(arg)

[eyaleizenberg]

I am facing the same issue:

Timecop.freeze(Time.at(@target_timestamp))
=> 2015-04-30 11:10:00 +0300

Timecop.freeze(@target_timestamp)
=> 2060-08-26 19:20:00 +0300

This is really weird.

[margaretdax]

Yes, it's very side effect heavy. Based on when you call the method you'll get a different timestamp. For the purpose of interacting with fixture data this is pretty annoying behavior, as it's not very easy to spot what's going on at first. If this set the time to the timestamp provided the functionality and contract is clear, and people don't have to dig around in the source :)

I'd consider this to be something for a major version release since I think it might break code that does use it as a Time.now + timestamp function.

[OtherCroissant]

It looks like this has something to do with the missing days in the gregorian calendar. For example when I do

Timecop.freeze(Date.new(1583)) do
  puts Date.today
end

it results in 1 jan 1583. Though, when I do

Timecop.freeze(Date.new(1582)) do
  puts Date.today
end

it results in 22 dec 1581. Which is not what you would expect.

In 1582, the gregorian calendar was introduced and they skipped 10 days to align the spring with 21 march. https://en.wikipedia.org/wiki/Gregorian_calendar So, I think this has something to do with the behaviour.