2009-09-12 58 views
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 
+0

生产机器是否也是mac? – Dolphin 2009-09-21 19:22:27

+0

@Dolphin - 我不这么认为(它托管在Heroku上) – 2009-09-21 19:54:28

+0

双启动OSX和Windows操作系统的人通常会遇到问题,因为OSX假定RTC是UTC,Windows假定它是当地时间。这个问题有可能类似吗? – Dolphin 2009-09-21 20:01:06

回答

1

看起来它假定在DB日期将被存储在本地时区这对2度的环境不同,然后将其将其转换为UTC。由于DB中的值基本相同,因此可以得到2个不同的UTC值。

“config/environment.rb”中config.time_zone的值是什么? 也是什么值的“选择created_at从注释其中id = 2028”?

+0

'config.time_zone'设置为“UTC”。 2028的'created_at'列在我的原始文章中(2028对应于我在制作示例时的Annotations.last) – 2009-09-13 23:39:13

+0

您只列出了rails所看到的created_at。我问的是存储在mysql中的实际值。 – 2009-09-14 19:11:08

+0

我更新了我的帖子,查询结果为 – 2009-09-19 02:16:33

0

这是我以前遇到过的问题。

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

0

也许一台或两台机器的系统时间设置设置为本地时区而不是UTC。如果是这样的话,那么它会混淆UTC时间(int)的实际值。

有许多方面需要检查在两台机器上:

  • 系统时区
  • 本地(用户)过程时区
  • 数据库系统时区
  • 数据库的本地时区
0

这似乎不能被其中一方报告当地时间为UTC时间:东部时间为4小时ay来自UTC,太平洋时间距离7小时,但你会看到3小时的差异,而不是4或7小时的差异。

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

也许这是SQLite后端ActiveRecord中的错误?因为它好像是那种被广泛使用的代码很久以前就被捕获并被压扁的东西。

4

在Heroku和开发机器之间移动数据库时,看起来这是一个问题。运行SQL查询直接给我这个:

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

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

同样的问题,正好三个小时的班次。通过Tap的源头,Gem heroku使用数据库同步,并没有提供任何可能出错的线索。我已经打开了一个heroku支持票,我会用我发现的内容更新这篇文章。

更新: 来自Heroku的Ricardo和Morten回答。在命令行上指定TZ,如下所示:

TZ=America/Los_Angeles heroku db:pull 
+0

谢谢!很高兴看到我不是唯一一个 – 2009-11-02 02:46:21

相关问题