Setting the TimeZone in an initializer instead of application.rb has unexpected effect

[zavan]

Steps to reproduce

Instead of setting config.time_zone in application.rb (which works properly), create an initializer and set the timezone there with: Rails.application.config.time_zone = 'Brasilia'.

This works with other configurations, such as Rails.application.config.active_job.queue_adapter = :delayed_job, so it probably should work for setting the timezone too.

Expected behavior

When running Rails.application.config.time_zone the configured timezone is shown, and everything, including Time.zone, must be in the configured timezone.

Actual behavior

When running Rails.application.config.time_zone the configured timezone is shown, but everything, including Time.zone, is still UTC.

System configuration

Rails version:
master at f03c27c (Rails 5.0.0.beta3)

Ruby version:
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]

[maclover7]

Can you create an executable test script using one of the templates here, that would demonstrate the problem you are seeing?

[zavan]

@maclover7 I'm not sure how to setup this so that I can call Rails.application.config.time_zone = 'Brasilia' and assert what Rails.application.config.time_zone and Time.zone returns.

[repinel]

This seems to happen because the Railtie initializer in active_support/railtie.rb runs before the initializer files.

Having it as a after_initialize could be a fix. In the same file, wouldn't the same apply to config.beginning_of_week?

[vipulnsward]

Rails.application.config.active_job.queue_adapter is a class attribute on AJ. Its ok to override it(In fact we have a feature to allow to do so on every class.).

Allowing this for Time.zone_default is going to be problematic. Imagine this flow:

• We do/don't set Time.zone_default as is right now(before initializers).
• Some user or internal initializer uses some time zone config.
• Some other user initializer sets another time zone config using Rails.application.config.time_zone
• We end up with different time zone defaults run for one set of initializers vs the ones that are run after setting Rails.application.config.time_zone.

I think we should document this instead, thoughts @fxn ?

[alfie-max]

@vipulnsward I get your point regarding the flow you described. But isn't that the case with all the other config ? I mean whatever is set in application.rb gets initialised before the ones specified in other initializer files (which there may or may not be more than once) and later on get overridden.

Which i believe happens here too with Rails.application.config.time_zone, as @zavan has described its value gets changed. But just the expected behaviour is what's missing. So isn't that an anomaly? that the config value and the expected behaviour are different?

Please do correct me if i'm wrong somewhere.

[fxn]

In general, configuration specific to the application object needs to go either in config/application.rb or in config/environments/#{Rails.env}.rb, you can't just assign to an arbitrary config point in config/initializers and expect it to work.

Setting the time zone was one of the examples in the generated config/application.rb, but that was deleted in 28dcadc.

This is by design. In general Rails does not know about its components. Rails has configuration settings that components pick in their railties initialization, so they are expected to have their value by the time the initialization of railties run. If you check a standard list of initializers you'll see the ones in config/initializers get executed very late in the boot process (load_config_initializers).

Unfortunately this is not very well documented right now, but at least you know now you need to move that setting.

[neves]

@zavan , I can confirm the problem.
application.rb suggest the follow: "Application configuration should go into files in config/initializers"
but config.time_zone = 'Brasilia' does not work there, just inside application.rb

[alfie-max]

@neves, please see to the explanation provided by @fxn

[frenkel]

@alfie-max what are you pointing at? He didn't provide a solution, right?

[steventen]

# Application configuration should go into files in config/initializers ... in config/application.rb is confusing