Time.freeze doesn't seem to freeze time

[davidpdrsn]

I'm having some issues with Timecop.freeze. It works fine on OS X, but the same test fails on Arch Linux. Not sure if this is because of Timecop or rspec.

I've an example app with a failing test

https://github.com/davidpdrsn/timecop-test-failure

User spec

require "rails_helper"

describe User do
  describe "seen!" do
    it "sets last_seen" do
      Timecop.freeze(Time.now) do
        user = User.create name: "Bob"

        user.seen!

        expect(User.find(user.id).last_seen).to eq Time.now
      end
    end
  end
end

User model

class User < ActiveRecord::Base
  def seen!
    update last_seen: Time.now
  end
end

Test output

F

Failures:

  1) User seen! sets last_seen
     Failure/Error: expect(User.find(user.id).last_seen).to eq Time.now

       expected: 2015-03-22 20:49:15.899984404 +0100
            got: 2015-03-22 19:49:15.899984000 +0000

       (compared using ==)

       Diff:
       @@ -1,2 +1,2 @@
       -2015-03-22 20:49:15 +0100
       +Sun, 22 Mar 2015 19:49:15 UTC +00:00

     # ./spec/models/user_spec.rb:11:in `block (4 levels) in <top (required)>'
     # ./spec/models/user_spec.rb:6:in `block (3 levels) in <top (required)>'
     # -e:1:in `<main>'

Finished in 0.01691 seconds (files took 0.22619 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./spec/models/user_spec.rb:5 # User seen! sets last_seen

Might be related to #97, but as I said it works on OS X, but not Arch Linux.

[sindrenm]

I am experiencing the same on Arch, although my timezone doesn't change like yours do. On OS X Yosemite everything is working fine.

[sindrenm]

Here is the error I am getting:

Failure/Error: expect(user.reload.last_heist_at).to eq Time.zone.now

  expected: 2015-05-09 22:52:56.280502338 +0200
       got: 2015-05-09 22:52:56.280502000 +0200

  (compared using ==)

  Diff:

[sindrenm]

Hang on! This looks like it might be a difference in the database setup or something. Notice how the actual timestamps are less accurate than what is expected? The same happens in your example, @davidpdrsn. The timestamps are probably persisted with less precision in our Arch installations or something.

[sindrenm]

Yeah, that's it. Looking at the issue you referenced earlier, @davidpdrsn, this was mentioned in #97 (comment).