views:

578

answers:

1

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.

+2  A: 

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.

MarkusQ