Comments (14)
Looking now, this seems to be similar (if not the same?) as issue #7.
from timecop.
Issue #7 occurs due to the fact that calling #utc on an instance of Time actually mutates the Time instance. I'm pretty sure that I know what the workaround to it is, I just haven't gotten around to it.
Calling #getlocal regardless allowed me to normalize the "figure out what time is being passed in in the first place" problem. Furthermore, iirc, it helps me to deal with DST (which is a huge PITA).
Are you actually seeing any incorrect behavior? Timecop is a testing library after all. I'm not sure that the concerns you have (different time zones on different machines) are particularly relevant.
from timecop.
Yeah, I just brought that up in hopes of shoring up my arguement.
But I am experiencing what I consider a bug. I call TimeCop.freeze(Time.gmt(...)) and I expected it to be GMT time. I choose to call gmt rather than local so that I know that the time (and potentially, the date) is correct, regardless of where the computer is, or where the tests are run. Instead, due to the call to #getlocal, the frozen time is 4 hours behind the GMT time, causing my tests to be incorrect.
Now, if DST is such a pain (I haven't done enough time related testing to really know) and the solution is to call #getlocal, why not also add in a case for GMT/UTC times? Time provides a #gmt? method you could call, and my idea is, if it returns true, just use the pass Time object directly, rather than calling #getlocal.
If you want, I could write the patch myself.
from timecop.
It wouldn't hurt to write up the patch yourself. I don't see myself being able to get to this anytime soon.
from timecop.
I agree with evaryont, this is a major issue for us as well. parse_time converts all Time objects passed to it to local system time, ignoring the time zone setting. This is especially important when testing rails apps where a time zone setting exists at the application level. When I do the following, I expect Timecop to freeze time at the utc time zone, but instead, freezes and returns a time object based on the timezone of my system, which is in PST:
Timecop.freeze(Time.utc(2010, 12, 12)) # => Sat Dec 11 19:00:00 -0500 2010
Does this use case make sense? Also, is timecop trying to support the rails use-case, where application/user-specific time zone information is important?
from timecop.
Yes, this use case makes sense. Honestly I've never used rails' time zone setting (also use UTC). I think that an older version of Timecop will actually behave properly for your use case. I think I changed the behavior between 0.3.1 and 0.3.4 (0.3.2 and 0.3.3 were yanked) when I made efforts to properly handle DST (which is a bitch to support across timezones). Try 0.3.1 and also try 0.2.0. I'm curious if those work for you.
from timecop.
This was a deal-breaker for me. My specs were failing because I'm in Melbourne/Australia, and I needed to test something at Time.utc(2009, 3, 9)
, which logically is midnight, 9th March 2009, right? Or 1am if you're using Timecop. I don't understand the need for using local time, rather than just using the time given. That's where this issue is arising. DST between timezones.
I've ended up with the K.I.S.S approach, that granted, might not work for everyone, but works for us where Timecop broke our tests:
class Time
class << self
attr_accessor :mock_time
def now_with_mock_time
@mock_time || now_without_mock_time
end
alias_method_chain :now, :mock_time
def be(a_time)
raise ArgumentError, "Time.be requires a block, but none was given" unless block_given?
original_mock_time = @mock_time
@mock_time = a_time
yield
ensure
@mock_time = original_mock_time
end
end
end
When the time is frozen with this approach, Time
, DateTime
and Date
all see the current time is whatever it is frozen at, at least in ruby 1.9.2.
I hope this gets fixed.
from timecop.
Yeah please fix this, thats nasty..!
from timecop.
+1
from timecop.
Just as another datapoint, my tests started failing this morning after the time change. Reverting to 0.3.1 fixed it.
I freeze to a GMT time and run some jobs, then check the dates. DateTime.now.in_time_zone("UTC") changed when my computer's clock changed.
from timecop.
Our tests also starting failing today:
Timecop.freeze(Time.utc(2011, 1, 1, 0, 0, 0))
puts DateTime.now.utc
2010-12-31T23:00:00+00:00 # wtf?
from timecop.
Is that fixed?
from timecop.
I'm going to close this issue as it seems to not be going anywhere, if this is still a problem then please open a fresh issue and we can discuss.
from timecop.
Is this fixed?
new_time = Time.utc(2016,10,28, 10, 24, 00)
Timecop.freeze(new_time)
t1 = Date.today.to_time.advance(days: -2)
t1 is 2016-10-26 00:00:00 +0100. Why +0100 is here?
from timecop.
Related Issues (20)
- Is call to Timecop.travel(some random time) atomic in nature? HOT 1
- Time#travel should be side-effect free and not resume system clock HOT 10
- .
- Timecop.thread_safe = true by default HOT 1
- Timecop handles GMT/UTC Time objects incorrectly HOT 2
- Doesn't work for `Rails.cache` with `expires_in` HOT 2
- ruby 3.1 support
- Date.strptime returns wrong month for %Y HOT 6
- %W is not handled properly HOT 1
- Ruby 2.5 seems to work? HOT 4
- Using timecop with psych 4.0.5, behavior differs between the test environment and other environments HOT 3
- Timecop.scale to mock existing times HOT 2
- Timecop.freeze not working with expect().to receive HOT 3
- Test
- Need a proper test for making sure we don't change timezones inadvertently
- DateTime parse without date not working properly HOT 5
- DateTime.parse("Wednesday 12:00") format is always returning midnight HOT 1
- Time.now sometimes has greater-than-nanosecond precision when called under Timecop.travel HOT 3
- DateTime.parse does not handle CWeek correctly
- Mocking `Process.clock_gettime` causes `Concurrent::IVar` with timeout to wait indefinitely HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from timecop.