Holidays not working when config.time_zone is changed in application.rb
I am using the business time gem and it seems that holidays are not being accounted for. Here's an example of what my config looks like and some console outputs.
/config/business_time.yml:
business_time:
beginning_of_workday: 8:00 am
end_of_workday: 1:00 pm
holidays:
- Feb 18th, 2013
- May 27th, 2013
- July 4th, 2013
- Sep 2nd, 2013
- Nov 28th, 2013
- Nov 29th, 2013
- Dec 25th, 2013
- Dec 31st, 2013
- Jan 1st, 2014
work_week:
- mon
- tue
- wed
- thu
- fri
in Rails console:
1.9.3p327 :024 > BusinessTime::Config.holidays
=> [Mon, 18 Feb 2013 00:00:00 PST -08:00, Mon, 27 May 2013 00:00:00 PDT -07:00, Thu, 04 Jul 2013 00:00:00 PDT -07:00, Mon, 02 Sep 2013 00:00:00 PDT -07:00, Thu, 28 Nov 2013 00:00:00 PST -08:00, Fri, 29 Nov 2013 00:00:00 PST -08:00, Wed, 25 Dec 2013 00:00:00 PST -08:00, Tue, 31 Dec 2013 00:00:00 PST -08:00, Wed, 01 Jan 2014 00:00:00 PST -08:00]
1.9.3p327 :025 > Time.now
=> 2013-05-21 14:57:18 -0700
1.9.3p327 :026 > 4.business_days.from_now
=> Mon, 27 May 2013 14:57:42 PDT -07:00
it clearly shows may 27th as a holiday, yet it chooses may 27th as a viable business day. Same with July 4th. I don't think its a timezone issue because july 3rd and july 5th don't trigger as a holiday either.
1.9.3p327 :021 > 31.business_days.from_now
=> Wed, 03 Jul 2013 14:56:21 PDT -07:00
1.9.3p327 :022 > 32.business_days.from_now
=> Thu, 04 Jul 2013 14:56:24 PDT -07:00
1.9.3p327 :023 > 33.business_days.from_now
=> Fri, 05 Jul 2013 14:56:28 PDT -07:00
My project gem specs:
ruby 1.9.3p327 rails 3.2.11 business_time 0.6.1
EDIT:
it seems that updating the config.time_zone in application.rb is causing the issue. FOr instance, if i set:
config.time_zone = 'Pacific Time (US & Canada)'
then business_time holidays fail.
Anyone? Are holidays working for everyone else? I don't really see how I'm doing anything wrong with configuring the holidays for it to be an issue on my end, but if it is, i'd be glad to know what I'm doing wrong.
Adnan: In Rails console, run the following, does it return false?
date = Date.parse(2013, 05, 27)
Time.workday?(date)
@marshallshen : This is the output from my rails console:
1.9.3p327 :003 > date = Date.parse('2013/05/27') => Mon, 27 May 2013 1.9.3p327 :004 > Time.workday?(date) => true 1.9.3p327 :005 > BusinessTime::Config.holidays => [Mon, 18 Feb 2013 00:00:00 PST -08:00, Mon, 27 May 2013 00:00:00 PDT -07:00, Thu, 04 Jul 2013 00:00:00 PDT -07:00, Mon, 02 Sep 2013 00:00:00 PDT -07:00, Thu, 28 Nov 2013 00:00:00 PST -08:00, Fri, 29 Nov 2013 00:00:00 PST -08:00, Wed, 25 Dec 2013 00:00:00 PST -08:00, Tue, 31 Dec 2013 00:00:00 PST -08:00, Wed, 01 Jan 2014 00:00:00 PST -08:00]
Ok, so i figured out what the issue is. business_time holidays seems to fail when the rails time zone is not set to UTC. I currently have this line in my application.rb:
config.time_zone = 'Pacific Time (US & Canada)'
When i comment this out, the holidays work. However, i need to keep that as my time zone.
This gem says that's its timezone agnostic so I'm going to assume this is a bug.
OK, i dug through the code deeper and found the issue. My holidays seem to be storing in BusinessTime::Config.holidays as TimeWithZones on initialize instead of Dates. I am using the default initializer with the code:
BusinessTime::Config.load("#{Rails.root}/config/business_time.yml")
and business_time.yml file is shown in my first post.
When i update my /initializers/business_time.rb file to:
BusinessTime::Config.load("#{Rails.root}/config/business_time.yml")
BusinessTime::Config.holidays = BusinessTime::Config.holidays.map(&:to_date)
the holidays are stored as Dates and everything works as planned.
I agree, sounds like a bug. Can you write a test to expose it or better yet, include a fix in a pullup request?
@AdnanTheExcellent's solution solved the problem here. I'm using a different default time_zone as well.
Ok, I'm prepping for a new release this weekend, and this is top of my list. We put a lot of work into dealing with timezones... It is said that every software engineer eventually learns to hate timezones, and this proves that point
Awesome. Glad this is going to get patched up in a more elegant solution than what i did.