2

出于某种原因，在开发（我的本地 Mac）和生产（Heroku）中出现了不同的时间。看看：（就在这样做之前，我做了一个heroku db:pull，所以数据库应该是相同的）

生产（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"

开发（我的 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"

由于created_at时间相差 3 小时，我认为这与 EDT 和 PDT 之间的 3 小时差异有关，但我不确定发生了什么。

编辑：这是原始数据的样子：

sqlite> Select created_at from annotations where id = 2028;
2009-09-12T09:51:33-04:00
4

5 回答 5

4

在 Heroku 和您的开发机器之间移动数据库时，这似乎是一个问题。直接运行 SQL 查询给了我这个：

Local: {"created_at"=>"2009-10-30 22:34:55.919586"}

Remote: {"created_at"=>"2009-10-31 01:34:55.919586"}

同样的问题，正好是三个小时的班次。查看 Taps 的源代码，Gem heroku 用于 DB 同步，并没有提供任何线索来说明这里可能出现的问题。我已经打开了一张 heroku 支持票，我会用我发现的内容更新这篇文章。

更新：来自 Heroku 的 Ricardo 和 Morten 回复了。在命令行上指定 TZ，如下所示：

TZ=America/Los_Angeles heroku db:pull
于 2009-11-02T01:25:11.727 回答
1

看起来它假设数据库中的日期存储在您的本地时区中，这对于 2 个环境是不同的，然后将其转换为 UTC。因为 DB 中的值本质上是相同的，所以你会得到 2 个不同的 UTC 值。

“config/environment.rb”中 config.time_zone 的值是多少？“从 id=2028 的注释中选择 created_at”的值是多少？

于 2009-09-13T14:15:02.023 回答
0

这也是我之前遇到的一个问题。

如果您在 Rails 控制台上执行 Annotation.last.created_at 之类的操作，则结果已经应用了时区。您应该通过 mysql 控制台查看 mysql 中的“纯”日期:-)

于 2009-09-15T12:43:45.970 回答
0

也许其中一台或两台机器的系统时间设置设置为本地时区，而不是 UTC。如果是这种情况，那么 UTC 时间（int）实际上是什么值会让人感到困惑。

在两台机器上都有许多需要检查的区域：

  • 系统时区
  • 本地（用户）进程时区
  • 数据库系统时区
  • 数据库本地时区
于 2009-09-18T19:33:31.660 回答
0

这似乎无法通过一个或另一个将其本地时间报告为 UTC 时间来解释：东部时间距 UTC 4 小时，太平洋时间距 7 小时，但您看到的是三个小时的差异，而不是4 小时或 7 小时的差异。

似乎他们俩都产生了不正确的输出。SQLite 明确表示 09:51 时间应该是 -04:00 时间，即东部时间，但 Rails 在一种情况下错误地声称它是 UTC——而在另一种情况下，它将它从东部转换为太平洋，然后错误地声称结果是 UTC。

也许这是 ActiveRecord 的 SQLite 后端中的一个错误？因为如果它出现在广泛使用的代码中，它似乎早就被抓住并压扁了。

于 2009-09-20T18:34:20.703 回答