-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0.4.5 changed timezone comparison behavior #35
Comments
I can't say for sure without seeing that code block or a reproduced failing test. |
From the test's inspect output, it looks like you're comparing a |
Agreed @ches, the only change in 0.4.5 was to make time instance type consistent for comparisons so if you're having a problem now it's likely because you were comparing instances inconsistently before. |
I just discovered that my use of Timecop was incorrect, and that is probably what was causing this problem. I didn't know that I had to do The top example in the Readme is good and clear, so I'm not sure where I got the idea. But I'll submit a tweak to the other example in the readme just in case others run into the same problem. Thanks for Timecop!! |
ack, i take it back, that wasn't what caused my issue. I'm still having the issue, and
(they are identical) suspecting that the difference is sub-second, I switched the comparison to /cc @ches |
this spec:
used to pass with 0.4.4, but now fails with 0.4.5, with the message:
If I use pry to set a breakpoint with 0.4.4 and 0.4.5, I observe:
@t.to_f
and@object.attribute.to_f
are indeed identical as they should beSo, my guess: pry is doing its timefreezing job, and the
Time
objects are the same, but for some reason the comparison is now taking the timezone into consideration where before it was not. Is this expected/possible?The text was updated successfully, but these errors were encountered: