rails/rails — pull request #6344 by erichmenge (2012-05-16 03:32:47+00:00)
Title: SQLite3 doesn't actually support the 'time' type.

Relates to #6247.

SQLite3 does not support the 'time' data type. I feel like we shouldn't pretend it does.

As it is now, if you create a new record with time only, the year gets set as the current year in the database. However, as in issue #6247 when you do `Alert.all` it shows the year as being 2000. Subsequently you get this behavior:

``` irb
irb(main):001:0> Alert.create(start: Time.now)
(0.1ms) begin transaction
SQL (30.6ms) INSERT INTO "alerts" ("created_at", "start", "updated_at") VALUES (?, ?, ?) [["created_at", Wed, 16 May 2012 03:27:27 UTC +00:00], ["start", 2012-05-15 22:27:27 -0500], ["updated_at", Wed, 16 May 2012 03:27:27 UTC +00:00]]
(2.1ms) commit transaction
=> #
irb(main):002:0> Alert.all
Alert Load (0.4ms) SELECT "alerts".* FROM "alerts"
=> [#]
irb(main):003:0> Alert.where('start < ?', Time.now - 5.minutes)
Alert Load (0.3ms) SELECT "alerts".* FROM "alerts" WHERE (start < '2012-05-16 03:22:46.609478')
=> []
```
It isn't very consistent to show `start: "2000-01-01"` and yet not find it. The reason is it really has year 2012 in the database.

As an aside, I had to add:

``` ruby
ActiveRecord::Base.time_zone_aware_attributes = false
ActiveRecord::Base.default_timezone = :local
Time.zone = nil
```
to a couple of the tests, because when I changed line 955 to skip SQLite3 adapter, those lines getting skipped at the end were causing those other two tests to fail. I don't see any tests that set those attributes and not set them back, but I guess something funny is going on there.