Strange temporary inconsistencies between production and development
For some reason, times appear differently in development (my local Mac) and production (Heroku). Take a look: (Just before this I did heroku db:pull
, so the databases must be identical)
Manufacturing (Heroku)
>> Annotation.last.id
=> 2028
>> Annotation.last.created_at
=> Sat, 12 Sep 2009 06:51:33 UTC +00:00
>> Time.zone
=> #<ActiveSupport::TimeZone:0x2b4972a4e2f0 @tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, @utc_offset=0, @name="UTC">
>> Time.now.zone
=> "PDT"
Development (my MacBook Pro)
>> Annotation.last.id
=> 2028
>> Annotation.last.created_at
=> Sat, 12 Sep 2009 09:51:33 UTC +00:00
>> Time.zone
=> #<ActiveSupport::TimeZone:0x23c92c0 @tzinfo=#<TZInfo::DataTimezone: Etc/UTC>, @utc_offset=0, @name="UTC">
>> Time.now.zone
=> "EDT"
Since the time created_at
differs by 3 hours, I assume it is due to the 3 hour difference between EDT and PDT, but I'm not sure what is going on.
EDIT: . This is what the raw data looks like:
sqlite> Select created_at from annotations where id = 2028;
2009-09-12T09:51:33-04:00
source to share
It looks like this is a problem when moving databases between Heroku and your development machine. Executing the SQL query directly gives me this:
Local: {"created_at"=>"2009-10-30 22:34:55.919586"}
Remote: {"created_at"=>"2009-10-31 01:34:55.919586"}
The same problem, exactly a three-hour shift. Looking at the source for Taps, Gem heroku uses to sync the DB, doesn't give any clues as to what might be wrong here. I have opened a heroku support ticket and I am updating this post with what I find.
UPDATE: Ricardo and Morten from Geroku answered. Specify TZ on the command line as follows:
TZ=America/Los_Angeles heroku db:pull
source to share
It looks like it assumes that the dates in the DB are stored in your local timezone, which is different for the two environments, and then translates it to UTC. since the value in the DB is essentially the same, you get 2 different UTC values.
What is the value of config.time_zone from your "config / environment.rb"? Also what is the meaning of "Select created_at from annotations where id = 2028"?
source to share
It is possible that one or both machines have the system time set to the local time zone instead of UTC. If this happens then it will confuse what value UTC (int) time has.
There are several areas on both machines:
- system time zone
- the local (user-defined) time zone of the process
- Database system time zone
- local timezone of the database
source to share
This does not seem to be explained by any reporting of its local time as UTC time: Eastern time is 4 hours from UTC and Pacific Time is 7 hours, but you are seeing a three hour difference, not a 4 or 7 hour difference.
Both seem to produce the wrong conclusion. SQLite explicitly says that 09:51 should be -04: 00 time, which is Eastern time, but Rails incorrectly states that UTC in one case, and in another case, it translates it from Eastern to Pacific, then incorrectly asserting that the result is UTC.
Perhaps this is a bug in SQLite for ActiveRecord? Because it looks like it would have been caught and flattened long ago if it were in widely used code.
source to share