-
Notifications
You must be signed in to change notification settings - Fork 465
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
Daylight Savings not handled properly #147
Comments
Probably related, this morning, my Chronic calls started straight up failing right at 2AM when DST kicked over.
Is now nil. Argh?
I'm currently setting the timezone like so, if that matters:
Setting the timezone to 'UTC' seems to fix it. But I am wondering why this worked all the way until yesterday but not today? |
I ran into the exact same issue today described by @travisbell above. |
I also encountered the same error as @bricker - has there been any updates on this? |
No there hasn't, I'm struggling to find time for Chronic at the moment. Hoping to start hitting some of these as soon as possible |
@injekt I have some time to work on this. I'll fork and send a pull request if I have any luck. Do you have an idea of where in the codebase I might start looking to find the source of the bug? |
I don't know if this is the same issue but I noted the following in issue #179 1.9.3p362 :021 > Time.current Interestingly, specifying "April 1st" works fine whereas "20 days from now" doesn't work. Chronic 0.9.1 |
@markerdmann sorry I hadn't noticed your message until today. I can't reproduce the original issue so it'll probably take me a little longer to fix. Usually I would enable debug mode ( |
We ran into this in floraison/et-orbi#23 as well. I think these lines are questionable: chronic/lib/chronic/repeaters/repeater_time.rb Lines 81 to 96 in 2b1eae7
Try passing in Time.parse('2020-11-01 00:00:00')
=> 2020-11-01 00:00:00 -0700
Chronic.parse('2020-11-01 00:00:00')
=> 2020-11-01 01:00:00 -0700 Why did Chronic advance an hour like that? When a date like this is passed in If I try to get rid of this diff --git a/lib/chronic/repeaters/repeater_time.rb b/lib/chronic/repeaters/repeater_time.rb
index 0a496e7..208553e 100644
--- a/lib/chronic/repeaters/repeater_time.rb
+++ b/lib/chronic/repeaters/repeater_time.rb
@@ -87,21 +87,21 @@ module Chronic
catch :done do
if pointer == :future
if @type.ambiguous?
- [midnight + @type.time + offset_fix, midnight + half_day + @type.time + offset_fix, tomorrow_midnight + @type.time].each do |t|
+ [midnight + @type.time, midnight + half_day + @type.time + offset_fix, tomorrow_midnight + @type.time].each do |t|
(@current_time = t; throw :done) if t >= @now
end
else
- [midnight + @type.time + offset_fix, tomorrow_midnight + @type.time].each do |t|
+ [midnight + @type.time, tomorrow_midnight + @type.time].each do |t|
(@current_time = t; throw :done) if t >= @now
end
end
else # pointer == :past
if @type.ambiguous?
- [midnight + half_day + @type.time + offset_fix, midnight + @type.time + offset_fix, yesterday_midnight + @type.time + half_day].each do |t|
+ [midnight + half_day + @type.time, midnight + @type.time + offset_fix, yesterday_midnight + @type.time + half_day].each do |t|
(@current_time = t; throw :done) if t <= @now
end
else
- [midnight + @type.time + offset_fix, yesterday_midnight + @type.time].each do |t|
+ [midnight + @type.time, yesterday_midnight + @type.time].each do |t|
(@current_time = t; throw :done) if t <= @now
end
end Tests like the following fail: chronic/test/test_daylight_savings.rb Lines 38 to 41 in 2b1eae7
|
Previously the offset change for Daylight Savings was unnecessarily added all the time, resulting in this discrepancy when the local time was set to UTC-7: ``` Time.parse('2020-11-01 00:00:00') => 2020-11-01 00:00:00 -0700 Chronic.parse('2020-11-01 00:00:00') => 2020-11-01 01:00:00 -0700 ``` Each time we add an offset to a base time, we need to check whether this crosses Daylight Savings boundaries. Only if it does should we adjust the time by the offset. Closes mojombo#147
Previously the offset change for Daylight Savings was unnecessarily added all the time, resulting in this discrepancy when the local time was set to UTC-7: ``` Time.parse('2020-11-01 00:00:00') => 2020-11-01 00:00:00 -0700 Chronic.parse('2020-11-01 00:00:00') => 2020-11-01 01:00:00 -0700 ``` Each time we add an offset to a base time, we need to check whether this crosses Daylight Savings boundaries. Only if it does should we adjust the time by the offset. Closes mojombo#147
Previously the offset change for Daylight Savings was unnecessarily added all the time, resulting in this discrepancy when the local time was set to UTC-7: ``` Time.parse('2020-11-01 00:00:00') => 2020-11-01 00:00:00 -0700 Chronic.parse('2020-11-01 00:00:00') => 2020-11-01 01:00:00 -0700 ``` Each time we add an offset to a base time, we need to check whether this crosses Daylight Savings boundaries. Only if it does should we adjust the time by the offset. Closes mojombo#147
I think #396 fixes this problem. |
Daylight savings "falls back" in the states on November 4th, 2012, at exactly 2am. It goes backwards and repeats the 1am hour.
Those first two dates should return the same, and I would expect the last one to return 12pm. Hopefully this is a silly mistake I'm making, or there is a reasonable explanation. DST is a nightmare!
The text was updated successfully, but these errors were encountered: