views:

15

answers:

1

Here is the setup:

end_date = DateTime.parse('2010-01-01 12:00:00-04')

and sometimes it's initialized:

end_date = 1.days.ago

The question... do these named_scope(s) generate the same EXACT SQL?

named_scope :before, lambda { |end_date| 
     { :conditions => 
            ["overdraft_transaction_payments.created_at < ?", end_date] } 
}

and

named_scope :before, lambda { |end_date| 
     { :conditions => 
            ["overdraft_transaction_payments.created_at < ?", end_date.utc] } 
}

In the first example I use end_date and in the second I use end_date.utc.

(It may be important to note.... The DB server's OS is set to CDT, and the DB uses UTC internally. The rails server's OS is set to CDT and the application instance is set to EDT. I realize that this is probably not the optimum way to configure these systems, however, the issue at hand is the ActiveRecord output.)

For what it is worth my intuition says that the first example is going to generate a time string for the local TZ where the second is going to generate a UTC-0.

PS: Is there a mini test case I can use to validate my intuition?

+1  A: 

I believe under the hood the date is going to be converted with a call to ".to_s(:db)" and you can see in an IRB console session what that's going to return:

>> DateTime.parse('2010-01-01 12:00:00-04').to_s(:db)
=> "2010-01-01 12:00:00"
>> DateTime.parse('2010-01-01 12:00:00-04').utc.to_s(:db)
=> "2010-01-01 16:00:00"
>> 1.days.ago.to_s(:db)
=> "2010-08-12 18:01:09"
>> 1.days.ago.utc.to_s(:db)
=> "2010-08-12 18:01:13"
Teflon Ted
From your example #1 it looks like ".to_s(:db)" would not consider TZ as part of the formatting.
Richard
The lesson learned... when the timezones are so nutty, make sure you use the .to_s(db) explicitly in your SQL.
Richard