Giter Club home page Giter Club logo

Comments (5)

bokmann avatar bokmann commented on June 10, 2024

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?

from business_time.

shibz avatar shibz commented on June 10, 2024

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.

from business_time.

neilma avatar neilma commented on June 10, 2024

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...

from business_time.

bokmann avatar bokmann commented on June 10, 2024

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.

from business_time.

ziaulrehman40 avatar ziaulrehman40 commented on June 10, 2024

Did you guys understood each other? :D

from business_time.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.