5.10. Setting a Default Time Zone

Every time a model's datetime attribute is saved in the database, this becomes stored as a UTC time. The problem is that the dates and times presented to the visitor and the blog author are UTC times, rather than a predefined local time zone. When you click New Article you'll see that the default date and time selected are based on UTC, not the local time zone. This implies that if you want to schedule a post in the future for a certain "local time," you'll have to offset it (in your head) to obtain the UTC time. Likewise, having chosen the "long ordinal" presentation of the date and time, when showing an article the readers of your blog will just see an absolute numeric representation of the time and won't assume that it's a UTC time.

Figure 5.16. Figure 5-16

Depending on your application's requirements, this may or may not be a big deal. Luckily for you, Rails 2.2.2 provides excellent support for time zones and setting a predefined time zone for your application is extremely easy. I live in Toronto, so my time zone is Eastern Time (US & Canada). You can see a list of local time zones by running the rake task time:zones:local:

C:projectslog> rake time:zones:local
(in C:/projects/blog)

* UTC −05:00 *
Bogota
Eastern Time (US & Canada)
Indiana (East)
Lima
Quito

You can use rake time:zones:us to obtain only the US time zones matching the local time on your machine. If you'd like a list of all the time zones supported by Rails, run rake time:zones:all.

Once you've determined the time zone that you'd like to apply — usually the time zone of your computer or of your deployment server — you need to tell Rails that you'd like to use this instead of UTC for your dates and times. In the configenvironment.rb file change this line:

config.time_zone = 'UTC'

With the following or the time zone you're in:

config.time_zone = 'Eastern Time (US & Canada)'

Restart Mongrel, refresh the /articles page, and you will see that the times are now presented in the local time zone. Furthermore, if you head over to /articles/new the default time for the published_at field will be the current time in your local time zone as well.

Rails will still store the date and time values as UTC in the database, but will perform an automatic conversion for you when retrieving them from, or storing them in, the database. To verify this fire up the Rails console:

C:projectslog> ruby script/console
Loading development environment (Rails 2.2.2)
>>

This console works similarly to irb but it already has Rails' current environment loaded for you.

Try to evaluate the following expression:

>> Article.find(1).published_at
=> Fri, 11 Jul 2008 05:24:00 EDT −04:00

The result I obtained is local to my machine (which is what I'm after), however this may trick you into believing that the database holds that local date and time as well. This is not the case, as you can confirm by appending before_type_cast to the attribute published_at to obtain the date and time before the automatic conversion:

>> Article.find(1).published_at_before_type_cast
=> "2008-07-11 09:24:00"