Does this help clarify?
>> Date.methods.find_all {|m| m =~ /zone/}
=> ["zone_to_diff"] # this is a built-in that doesn't interact with
Rails timezones
>> Date.today.methods.find_all {|m| m =~ /zone/}
=> []
>> Time.now.methods.find_all {|m| m =~ /zone/}
=> ["in_time_zone", "zone"]
>> Time.methods.find_all {|m| m =~ /zone/}
=> ["zone", "zone=", "zone_default", "zone_default=", "use_zone",
"zone_offset"]
>> Date.today.to_time
=> Thu Sep 11 00:00:00 -0700 2008
>> Date.today.to_time.in_time_zone("UTC")
=> Thu, 11 Sep 2008 07:00:00 UTC +00:00
>> Date.today.to_time
=> Thu Sep 11 00:00:00 -0700 2008
>> Date.today.to_time.in_time_zone("Samoa")
=> Wed, 10 Sep 2008 20:00:00 SST -11:00
>> Date.today.to_time.in_time_zone("Samoa").to_date
=> Wed, 10 Sep 2008
>> Date.today
=> Thu, 11 Sep 2008
So a Date object has no time zone associated with it. When saving it
to the database, Rails would have no idea what time zone it is in, so
it is saved verbatim. 2008-09-10 will always be 2008-09-10. Now, as
soon as you start translating to Time objects, you get time zone
handling baked in. This lets you do crazy things like the third example.
I propose that Tracks always assume that Date values are in the active
user's local time zone (as per the user's preferences). If you want
the current date, do not use Date.today. Use User#date. Comments?_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
