2013-04-23 67 views
4
Time.use_zone('Pacific Time (US & Canada)') do 
    p Time.zone.now 
end 

我得到如下:=> Sun, 14 Apr 2013 20:30:53 PDT -07:00時區的困惑(1小時關閉)

然而,當我做Rails的時區選擇....它說-8:00很清楚。爲什麼在一個區域-7和另一個區域-8?

其他時間,如Hawaii這是-10:00時區不會抵消一個小時。

我想這已經是與DST,但我更好奇是否就意味着它的工作正常不當並沒有別的東西我需要做的。

最終我在日期選擇器中使用這個,我覺得很奇怪,當我使用Time.zone.parse(以及我的時區周圍的過濾器)時,它將所有東西都抵消了1小時。

感謝

編輯

繼承人類似的問題我也剛剛經歷與另一段代碼

2.0.0-p0 :006 > 
2.0.0-p0 :006 > u.meetups.in_future.first.meetup_time 
    Meetup Load (0.4ms) SELECT `meetups`.* FROM `meetups` WHERE `meetups`.`user_id` = 1 AND (meetup_time >= '2013-04-23 04:46:48') ORDER BY meetup_time ASC LIMIT 1 
=> Tue, 23 Apr 2013 05:43:00 UTC 00:00 
2.0.0-p0 :007 > 

請注意,在結果的差異相比,where子句。

編輯

這似乎爲CST正常工作,但PST是關閉的〜1小時?我覺得這都是同樣的問題,我只是想念一個難題。

+0

簡單的問題:你是否證實你的機器和SQL DB使用相同的時區信息?這真的只會導致數據庫(可能)的問題? – 2013-04-23 05:03:04

+0

我確定我的Rails應用程序時區是UTC,並且我在ApplicationController中還有一個around_filter,用於說明在選擇下拉列表中選擇的用戶時區 – st0rk 2013-04-23 05:04:39

+0

我對SQLite不夠熟悉(假設您使用的Rails默認dev DB)知道它是使用系統時區還是它自己的。但是MySQL有一個時區配置可以不同於那個(它應該是不同的)會導致時間以這種奇怪的方式抵消的機器。只是好奇,如果你檢查了。 – 2013-04-23 05:06:32

回答

2

輸出正確。太平洋夏令時偏差爲-7,而太平洋標準時間偏差爲-8。我的猜測是,「Rails時區選擇」(不管那是什麼)只是向您顯示「標準」偏移量,而不是當前偏移量。這在時區採集器中很常見。

夏威夷不實施任何形式的夏令時,因此可以解決您的第二個問題。

在您的第三點上,我將不得不更多地瞭解您的數據庫平臺,以回答爲什麼將值轉換爲UTC。鑑於這些是事件時間,我會說他們應該在UTC。他們也可能位於「聚會」地點的時區,但前提是也存儲了UTC的偏移量。但絕不應該在服務器的時區。

關於第四點,如果沒有更多細節,很難說出您的意思。如果你覺得有必要展開。