Do not set the configuration in Rails

[araslanov-e]

Rails 4.1.5

# config/initializers/working_hours.rb
WorkingHours::Config.time_zone = 'St. Petersburg'

$ bin/rails c 
> WorkingHours::Config.time_zone
=> #<ActiveSupport::TimeZone:0x0000000692f5d0 @name="St. Petersburg", @utc_offset=nil, @tzinfo=#<TZInfo::TimezoneProxy: Europe/Moscow>, @current_period=#<TZInfo::TimezonePeriod: #<TZInfo::TimezoneTransitionDefinition: #<TZInfo::TimeOrDateTime: 1301180400>,#<TZInfo::TimezoneOffset: 14400,0,MSK>>,nil>>

But

$ bin/rails s

in action (I'm use binding.pry)

> WorkingHours::Config.time_zone
=> #<ActiveSupport::TimeZone:0x000000055e6ff0 @name="UTC", @utc_offset=nil, @tzinfo=#<TZInfo::TimezoneProxy: Etc/UTC>, @current_period=#<TZInfo::TimezonePeriod: nil,nil,#<TZInfo::TimezoneOffset: 0,0,UTC>>>>

Why?

[Intrepidd]

Are you using a threaded web-server such as puma ?

WorkingHours configuration is stored in thread variables in order to allow multiple threads to have different configurations.

If you use a threaded web server the thread that initialises your app is not the same as the one that runs your action (that could change at every request depending on the server)

You have several choices :

• Set your timezone in a before_filter in your ApplicationController to be sure that for each request the configuration is set.
• Use specific configuration methods for your web server such as puma's on_worker_boot to set some config when launching new threads.

IMHO solution 1 should be simpler

Please let me know if this helped you.

Cheers

[araslanov-e]

I'm not using a threaded web-server, rails run with WEBrick.

[Intrepidd]

Based on my researchs, webrick spawns a new thread for each request, emptying the Thread.current variables.

I'll probably add a section in the readme to explain this issue more precisely

[araslanov-e]

And what do I do? В)

[Intrepidd]

Set your WorkingHours configuration in a before filter in ApplicationController :

class ApplicationController < ActionController::Base
   # ...

  before_filter :configure_working_hours

  private

  def configure_working_hours
    WorkingHours::Config.time_zone = 'St. Petersburg'
    WorkingHours::Config.working_hours = { ... }
    WorkingHours::Config.holidays = [] ...
  end

end

[araslanov-e]

bad solution B)

[Intrepidd]

Well working hours is pure ruby, and has no consciousness of rails, unless you come up with a good solution, I can't see any other solution.

Anyway, here's an example : if your app allows your users to have several time zones, you'll be obliged to set WorkingHours::Config.time_zone to the user time zone at the beginning of each request.

Same goes if the working hours configuration is persisted inside the database, you'll have to fetch it for each request.

[araslanov-e]

Just a moment!
My current time zone - 'Ekaterinburg'
App time zone - 'St. Petersburg'

$ bin/rails c
> Time.zone.now
=> Fri, 10 Oct 2014 10:37:07 MSK +04:00
> 1.hour.ago(Time.zone.now)                                                                                                              
=> Fri, 10 Oct 2014 09:37:28 MSK +04:00
> 1.working.hour.ago(Time.zone.now)
=> 2014-10-09 22:00:00 +0600
> WorkingHours::Config.time_zone                                                                                                         
=> #<ActiveSupport::TimeZone:0x000000057e9cd0 @name="St. Petersburg", @utc_offset=nil, @tzinfo=#<TZInfo::TimezoneProxy: Europe/Moscow>, @current_period=#<TZInfo::TimezonePeriod: #<TZInfo::TimezoneTransitionDefinition: #<TZInfo::TimeOrDateTime: 1301180400>,#<TZInfo::TimezoneOffset: 14400,0,MSK>>,nil>>

In 1.working.hour.ago time zone is reset

[jarthod]

What do you mean by "time zone is reset", if working hours is configured to use the St. Petersbourg timezone, it will of course return times in this time zone. did you expected it to return them in your timezone ?

[araslanov-e]

@jarthod no, it will return times in my time zone, but should in "St. Petersbourg"

[Intrepidd]

Alright there indeed is an issue with the time returned, the zone is incorrect, we're working on it.

However, this problem is totally different with the one you described when originally opening this issue

[araslanov-e]

@Intrepidd i can edit or create new issue for this B)

[Intrepidd]

I fixed the issue and released version 1.0.1

Regarding your original issue, We'll think about a more straight forward approach, but I'm closing this for now. If you have any other idea please open a new issue as this one is already clogged B)