views:

619

answers:

2

I have a rails time-based query which has some odd timezone sensitive behaviour, even though as far as I know I'm using UTC. In a nutshell, these queries give different answers:

>> Model.find(:all,:conditions=>['created_at<=?',(Time.now-1.hours).gmtime]).length
=> 279
>> Model.find(:all,:conditions=>['created_at<=?',(Time.now-1.hours)]).length
=> 280

Where the DB actually does contain one model created in the last hour, and the total number of models is 280. So only the first query is correct.

However, in environment.rb I have:

config.time_zone = 'UTC'

The system time zone (as reported by 'date') is BST (which is GMT+1) - so somehow this winds up getting treated as UTC and breaking queries.

This is causing me all sorts of problems as I need to parameterise the query passing in different times to an action (which are then converted using Time.parse()), and even though I send in UTC times, this 'off by one hour' DST issue crops a lot. Even using '.gmtime()' doesn't always seem to fix it.

Obviously the difference is caused somehow by an implicit conversion somewhere resulting in BST being incorrectly treated as UTC, but why? Doesn't rails store the timestamps in UTC? Isn't the Time class timezone aware? I am using Rails 2.2.2

So what is going on here - and what is the safe way to program around it?

edit, some additional info to show what the DB and Time class are doing:

>> Model.find(:last).created_at
=> Tue, 11 Aug 2009 20:31:07 UTC +00:00
>> Time.now
=> Tue Aug 11 22:00:18 +0100 2009
>> Time.now.gmtime
=> Tue Aug 11 21:00:22 UTC 2009
+3  A: 

The Time class isn't directly aware of your configured timezone. Rails 2.1 added a bunch of timezone support, but Time will still act upon your local timezone. This is why Time.now returns a BST time.

What you likely want is to interact with Time.zone. You can call methods on this like you would the Time class itself but it will return it in the specified time zone.

Time.zone.now # => Tue, 11 Aug 2009 21:31:45 UTC +00:00
Time.zone.parse("2:30 PM Dec 23, 2009") # => Sun, 23 Aug 2009 14:30:00 UTC +00:00

Another thing you have to be careful with is if you ever do queries on the database where you are comparing times, but sure to use the UTC time (even if you have a different time zone specified) because Rails always stores UTC in the database.

Item.all(:conditions => ["published_at <= ?", Time.now.utc])

Also, instead of Time.now-1.hour do 1.hour.ago. It is easier to read and Rails will automatically use the configured timezone.

ryanb
Interesting...is Time.utc a synonym for Time.gmtime? Also I get >> Time.zone=> #<ActiveSupport::TimeZone:0xb7b94c4c @utc_offset=0, @name="UTC", @tzinfo=#<TZInfo::DataTimezone: Etc/UTC>>. I think the problem is that to my way of thinking "Tue Aug 11 22:00:18 +0100 2009" and "Tue Aug 11 21:00:22 UTC 2009" refer to the same logical time. I guess that rails / ruby is simply ignoring the offset when building the SQL.
frankodwyer
I believe Time#utc is just an alias to Time#gmtime. Also, the timezone offset is ignored when dealing with a normal time (Time.now) but taken into account when using Time.zone.now. So best to always use Time.zone then you shouldn't have to call "utc" on it.
ryanb
thanks, that helps a lot. it's unintuitive to me that it works that way but at least I understand what's happening now. I've changed the code accordingly and it seems to have cleared the issue. Another thing that was throwing my code was that 1.years is not evenly divisible by 1.weeks as I expected it to be...I was doing a loop and getting an unrelated but similar error because of that.
frankodwyer
A: 

The TimeZone you need to set is UK, this will automatically handle BST

Time.zone = 'UK'
Time.zone.now
 => Sun, 17 Oct 2010 02:09:54 BST +01:00
MatthewFord