DateTime vs Time and ActiveRecord

example.md

>> ps.cancel_at
=> Fri, 05 Oct 2012 00:00:00 UTC +00:00
>> ps.cancel_at.class
=> ActiveSupport::TimeWithZone
>> ps.cancel_at = DateTime.new 2012, 11, 05
=> Mon, 05 Nov 2012 00:00:00 +0000
>> ps.save
   (0.2ms)  BEGIN
  Entity Load (0.5ms)  SELECT "entities".* FROM "entities" WHERE "entities"."id" = 2485 LIMIT 1
  Product Load (0.7ms)  SELECT "products".* FROM "products" WHERE "products"."id" = 32445 LIMIT 1
   (0.8ms)  UPDATE "product_subscriptions" SET "cancel_at" = '2012-11-05 00:00:00.000000', "updated_at" = '2012-10-05 22:16:42.029113' WHERE "product_subscriptions"."id" = 6762
   (1245.9ms)  COMMIT
=> true
>> ps.cancel_at = Time.local 2012, 11, 05
=> 2012-11-05 00:00:00 -0700
>> ps.save
   (0.2ms)  BEGIN
   (0.5ms)  UPDATE "product_subscriptions" SET "cancel_at" = '2012-11-05 07:00:00.000000', "updated_at" = '2012-10-05 22:17:32.097390' WHERE "product_subscriptions"."id" = 6762
   (0.4ms)  COMMIT
=> true
>> 

It's not necessarily that a due date is bad for dates with time zone. Maybe something needs to be finished by end of work day... you'd set the timestamp to `2012-10-05 6:00 PM MDT' and i would make sense for you and any others looking since it's due by that exact time.

The issue comes up when you have a date but are storing it as a datetime. Your nice "October 5th" date gets a silent "at midnight" appended to it, which messes with your coordination between time zones. If you don't intend to use a value as a DateTime then the database should store it as a Date

... Assuming Date objects in the database don't come with timezone support.

Something we could consider is our nice_date helper, perhaps adding a precise_date which normalizes to a set TZ regardless of logged_in user's TZ.

>> Time.utc(2012, 8, 13, 5, 0).in_time_zone(-6.hours).to_date
=> Sun, 12 Aug 2012
>> Time.utc(2012, 8, 13, 5, 0).to_date
=> Mon, 13 Aug 2012
>>