CODEWITHSUNDEEP
ruby-on-railstimezone
DanSingerman
DanSingerman

Reputation: 36532

Time Zone Weirdness in Rails

This is a really weird Rails problem - I have googled to see if this is related to a known bug, but haven't found anything - would be gratfeul for useful links as well as solutions.

I can boil the problem down to this:

If I start up my Rails App, and execute the following Rails code via an HTTP request.

Time.zone = 'Europe/London'
logger.info Time.zone.inspect

The log show this as the timezone

#<ActiveSupport::TimeZone:0x3d7438c @tzinfo=nil, @name="UTC", @utc_offset=0>

On the very next request (and most subsequent requests), the log for the same lines of code shows this

#<ActiveSupport::TimeZone:0x46cc100 @tzinfo=#<TZInfo::DataTimezone: Europe/London>, @name="Europe/London", @utc_offset=nil>

Anyone know what the hell is going on?

(I'm running Rails 2.3.2 if it helps)

Edit: It appears that Rails 2.2.2 doesn't have this problem, so I will revert to that for now.

Upvotes: 2

Views: 1540

Answers (1)

MarkusQ
MarkusQ

Reputation: 21950

ActiveSupport::TimeZone is intercepting Time.zone so that it can be pickled and restored. This is done lazily for some reason (which is why your changes don't show up immediately). There are cross session and multi-thread issues here, and I don't know the right of it. All I can say is:

  • What you are seeing really is happening
  • It's happening because it's coded that way
  • There are open TODO items about fixing this
  • It isn't clear (to me at least) what the globally "correct" behavior should be.

The basic problem with this sort of feature is that there's no clear way to discern the scope of the application programmer's intent from inside a setter. Is this a site-wide setting? A session wide setting? A passing fancy?

In the convention over configuration paradigm, such things need a convention to resolve them, and this area hasn't gotten one yet.

Upvotes: 4

Related Questions