Skip to content

Conversation

@RichGuk
Copy link

@RichGuk RichGuk commented Dec 30, 2014

No description provided.

giddie and others added 3 commits August 18, 2014 13:42
…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.
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).
@robwilliams
Copy link
Owner

Could the public holiday data be moved to the host app? Fetch the json from the government, store it in config, then define its path in an initializer?

If the json was converted to yaml it could then be used for any holiday data. Staff training days can be added etc :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants