Ensure that the cut-off time is in the same timezone as the extended object#1
Open
giddie wants to merge 6 commits intorobwilliams:masterfrom
Open
Ensure that the cut-off time is in the same timezone as the extended object#1giddie wants to merge 6 commits intorobwilliams:masterfrom
giddie wants to merge 6 commits intorobwilliams:masterfrom
Conversation
…object If we don't match the UTC offset, and the system timezone is not UTC, you end up with the following scenario: = Scenario 1 (correct) Time.now # 2014-08-15 15:30:00 +0100 Time.now.cut_off_time # 2014-08-15 16:00:00 +0100 Time.now.despatch_day # Fri, 15 Aug 2014 = Scenario 2 (incorrect) Time.zone.now # Fri, 15 Aug 2014 15:30:00 BST +01:00 Time.zone.now.cut_off_time # Fri, 15 Aug 2014 16:00:00 BST +01:00 Time.zone.now.despatch_day # Mon, 18 Aug 2014 The incorrect result in Scenario 2 is due to the fact that the ActiveSupport::TimeWithZone class wraps a UTC time object and maintains the timezone data separately. When DateExtension.despatch_day is called in Scenario 2, the context is: self # 2014-08-15 15:30:00 UTC cut_off_time # 2014-08-15 16:00:00 +0100 This comparison is incorrect due to the mismatch in timezones and produces the wrong result. The fix is to construct the cut_off_time based on the timezone of #self.
Author
|
Sorry, I spent ages trying to construct a spec to test this, but ran into a brick wall with the way the built-in Time class determines the local time zone. |
Owner
|
cheers @giddie, I'll see if I can add a test round it. |
|
Written that test yet? :) |
Switched to fetching the public holidays from the Government API. This ensures that the dates are always up to date and correct (with a server reboot anyhow).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If we don't match the UTC offset, and the system timezone is not UTC, you end up
with the following scenario:
Scenario 1 (correct)
Scenario 2 (incorrect)
The incorrect result in Scenario 2 is due to the fact that the
ActiveSupport::TimeWithZone class wraps a UTC time object and maintains the
timezone data separately. When DateExtension.despatch_day is called in Scenario
2, the context is:
This comparison is incorrect due to the mismatch in timezones and produces the
wrong result. The fix is to construct the cut_off_time based on the timezone
of #self.