Odd timezone behavior as soon as integrated with Rails

[shibz]

I ran into a very similar issue as #36, but different enough that I think it deserves a new ticket. I had a script using Business Time that was working just fine for a long time. As soon as I tried to integrate it into my Rails environment, my times started getting butchered. Here is the logic that seemed to be causing my issues:
https://github.com/bokmann/business_time/blob/develop/lib/business_time/time_extensions.rb#L107

Before I integrated Rails, Time.zone was nil. After adding Rails, Time.zone was always set to UTC. My timezone that I was trying to use (passed in the "time" variable) was in UTC-400.

For now I've solved this by setting my Rails timezone to the same timezone that I'm passing into my Business Time functions and that seems to have solved it, however as Business Time is supposed to be timezone agnostic, it would be nice to see this fixed and be able to go back to UTC in my rails app.

Edit: removed note about the new release that was mentioned in #36 after I noticed that the discussion was over a year old.

[bokmann]

ok, when I mean 'timezone agnostic', I mean that it makes no assumptions about timezones and should work if you use one consistently. If you set the Rails timezone to UTC and then pass in times that are in a different timezone than that, that probably will result in some pretty wonky behavior.

Lets say you set your workday to be 9:00am - 5:00pm, and your server time to be EST.
Monday, November 3rd, 2014 at 9:05 EST should be in an active workday...
What should "Monday, November 3rd, 2014 at 6:05 PST" be? I could see an argument made either way:
Argument #1 - "I configured my app so that business hours were 9 to 5, and this isn't between 9 and 5, so it shouldn't be inside of work hours".

Argument #2 - "I configured my app so that business hours were 9 to 5 in EST, and 6:05 PST is within 9-5EST, so this should be inside of work hours"

I do not think there is a 'right' answer to that question, there is only the answer you want in the context of your business requirements. Converting all times to a standard time zone before asking these questions removes the ambiguity.

Or am I missing your question?

[shibz]

I think you mixed up your EST and PST, but yes I understand what you're saying. Either argument would be fine if you picked one and stuck with it, but the current behavior is inconsistent. I've tried to demonstrate this below:

(FYI, my system timezone is Pacific time)

Scenario 1:

$ irb
irb(main):001:0> require 'business_time'
=> true
irb(main):002:0>
irb(main):003:0* BusinessTime::Config.beginning_of_workday = "8:00 am"
=> "8:00 am"
irb(main):004:0> BusinessTime::Config.end_of_workday = "6:00 pm"
=> "6:00 pm"
irb(main):005:0> time = Time.now
=> 2014-11-03 13:56:57 -0800
irb(main):006:0> Time.after_business_hours?(time)
=> false
irb(main):007:0> Time.before_business_hours?(time)
=> false
irb(main):008:0> Time.beginning_of_workday(time)
=> 2014-11-03 08:00:00 -0800
irb(main):009:0> Time.end_of_workday(time)
=> 2014-11-03 18:00:00 -0800
irb(main):010:0> # Now with UTC
irb(main):011:0* Time.after_business_hours?(time.utc)
=> true
irb(main):012:0> Time.before_business_hours?(time.utc)
=> false
irb(main):013:0> Time.beginning_of_workday(time.utc)
=> 2014-11-03 08:00:00 UTC
irb(main):015:0> Time.end_of_workday(time.utc)
=> 2014-11-03 18:00:00 UTC

You can see here that it seems to behave as described in argument 1. It just ignores the timezones and returns objects in the same timezone I passed in. However, the moment I load in my rails environment, the behavior changes, likely because Rails initializes my Time.zone variable from "nil" to "Eastern Time", which is currently default in my Rails environment.

[continued using same irb session as above]
irb(main):016:0> ENV['RAILS_ENV'] = "development"
=> "development"
irb(main):017:0> require "#{$ENVROOT}/rails-root/config/environment.rb"
=> true
irb(main):018:0> Time.after_business_hours?(time)
=> false
irb(main):019:0> Time.before_business_hours?(time)
=> false
irb(main):020:0> Time.beginning_of_workday(time)
=> Mon, 03 Nov 2014 08:00:00 EST -05:00
irb(main):021:0> Time.end_of_workday(time)
=> Mon, 03 Nov 2014 18:00:00 EST -05:00
irb(main):022:0> time
=> 2014-11-03 21:56:57 UTC

You can see I passed in a UTC time, but the functions are now suddenly converting my UTC time to EST time. The library has suddenly switched to the logic from argument 2 now that Rails is loaded.

The core of the problem seems to come down to the state of the Time.zone variable. If it's "nil", it consistently behaves as you described in argument 1. If you set Time.zone to anything else, it suddenly starts to behave as described in argument 2. This can be very confusing, especially when you develop the script outside of a rails environment where Time.zone is nil, and then once you integrate with Rails you find that it behaves completely different. I think that it should pick one or the other behavior and stick with it.

[neilma]

I got around this by setting timezone in application.rb: config.timezone = 'Melbourne'. Seems to be working for now...I'm using 4.business_hours.from_now, 8.business_hours.from_now, 18.business_hours.from_now, 45.business_hours.from_now.

Although it doesn't seem to work if I add a holiday to the business_time.yml. But I had to do it with Businestime::Config...

[bokmann]

As I read your transcript, I'm not surprised this is happening at all.

1. Your config for business_time specifies a beginning of workday as 8:00.
2. You have no timezone configuration.
3. business time uses UTC for your first transcript.
4. Rails loads all of its application state, and in the meantime metaprograms the heck out of date and time, adding all kinds of internal timezone support.
5. now your transcript is in EST, just as you instructed rails to do in your rails configuration.

When used with Rails, business_time should be configured in a rails initializer so that it is configured after rails is. While business_time is timezone-agnostic, rails is not. It is very timezone-opinionated, and that is what is causing this behavior.

I'm moving this conversation to the 'requires discussion' milestone, because I want to make sure we understand each other before I close this out.

[ziaulrehman40]

Did you guys understood each other? :D