config.timezone question

Hi,

Can anybody tell me the practical difference between using, in environment.rb ...

config.active_record.default_timezone = :utc

and

config.timezone = 'UTC'

I've got 2 apps that communicate data with each other. One is Rails 2.1 and config.rb contains the first. The other is Rails 2.3.4 and environment.rb contains the second.

I've Googled up an explanation that says that config.timezone "just let's Rails know the server is set to that timezone." I don't control the server and so, even if it happens to be true today, there's definitely a possibility that that could change without notice.

I need for both apps to store dates in UTC, and that seems to be happening, but the difference above makes me wonder if there's a 'storm brewing'. Do I need to use one or the other or both ?

Advice ?

TIA, Bill

Quoting bill walton <bwalton.im@gmail.com>:

Hi,

Can anybody tell me the practical difference between using, in environment.rb ...

config.active_record.default_timezone = :utc

and

config.timezone = 'UTC'

I've got 2 apps that communicate data with each other. One is Rails 2.1 and config.rb contains the first. The other is Rails 2.3.4 and environment.rb contains the second.

I've Googled up an explanation that says that config.timezone "just let's Rails know the server is set to that timezone." I don't control the server and so, even if it happens to be true today, there's definitely a possibility that that could change without notice.

I need for both apps to store dates in UTC, and that seems to be happening, but the difference above makes me wonder if there's a 'storm brewing'. Do I need to use one or the other or both ?

The difference is like in Linux/Unix the distinction between the hardware clock and the system clock. config.active_record.default_time says what timezone the database stores times. config.timezone says what timezone the server is in.

My laptop uses UTC for the hardware clock and usually Central US for the system clock. When I am on the West Coast, system time is Pacific US. The file timestamps are actually UTC, but displayed in the local system time. With the hardware clock set to the local time, rsyncing between the West Coast and my server at home would always send the files, because the timestamps never matched. With both systems using UTC hardware clock, that ceased to be a problem.

Back to Rails. I am developing a Rails app on my laptop that is deployed to Amazon's East Coast data center. The hardware clock on both systems is set to UTC. ActiveRecord is set to use UTC for the database. The config.timezone is set to UTC on the Amazon production server; since users can be anywhere in the world, that makes the most sense.

config.timezone for that apps and their users that are just on my laptop is always set to the local time.

You can see the difference in script/console, for a model Item:

jeff@odysseus:~/Rails/amethyst2> script/console Loading development environment (Rails 2.3.5)

Time.now

=> Wed Jan 20 12:07:27 -0600 2010

Time.zone.now

=> Wed, 20 Jan 2010 12:07:29 CST -06:00

item = Item.first

=> #<Item id: 252183, title: "Recycle, Reuse, Reduce", url: "http://austinblues.dyndns.org/?p=90&quot;, description: "When we lived in a house, the recycling bin was jus...", channel_id: 317, created_at: "2009-03-16 01:59:15", synopsis: "Recycle, Reuse, Reduce When we lived in a house, th...", dropped_at: nil, updated_at: "2009-12-16 23:29:02", ident: "http://austinblues.dyndns.org/?p=90&quot;, time: "Sat, 28 Feb 2009 16:48:44 +0000", published_at: "2009-02-28 16:48:44">

item.created_at

=> Sun, 15 Mar 2009 20:59:15 CDT -05:00

item[:created_at]

=> Mon Mar 16 01:59:15 UTC 2009

Unless the data is never going to be moved (or compared) acros time zones, I would set ActiveRecord to UTC. For the application timezone, look at the users. If they all are in the same timezone, use the local timezone. It makes debugging easier.

It took me a fair number of hours and attempts to understand how timezones are handled and get it correct in all parts of my application. I am clear that the app is aimed at the whole world, so the effort made sense. For an app that I expect to always stay just on my laptop, DB times are in UTC, since the laptop moves between timezones, but all times within the app are localtime.

HTH,   Jeffrey