我正在使用美國/紐約時區(qū)。在秋季，我們“退后”一個小時-實際上是在凌晨2點“獲得”一個小時。在過渡點發(fā)生以下情況：它是01:59:00 -04：00，然后一分鐘后變成：01 :00 :00 -05：00因此，如果您只是簡單地說“ 1:30 am”，那么您是指第一次還是1:30滾動還是第二次就不清楚了。我正在嘗試將計劃數(shù)據(jù)保存到MySQL數(shù)據(jù)庫，并且無法確定如何正確保存時間。這是問題所在：“ 2009-11-01 00:30:00”內(nèi)部存儲為2009-11-01 00:30:00 -04：00“ 2009-11-01 01:30:00”內(nèi)部存儲為2009-11-01 01:30:00 -05：00這是很好的，也是可以預(yù)期的。但是，如何將任何內(nèi)容保存到01:30:00 -04：00？該文檔沒有顯示對指定偏移量的任何支持，因此，當(dāng)我嘗試指定偏移量時，它已被適當(dāng)忽略。我想到的唯一解決方案是將服務(wù)器設(shè)置為不使用夏令時的時區(qū)，并在腳本中進行必要的轉(zhuǎn)換（為此我使用PHP）。但這似乎沒有必要。非常感謝您的任何建議。
3 回答
收到一只叮咚
TA貢獻1821條經(jīng)驗 獲得超5個贊
坦率地說，MySQL的日期類型已損壞，無法正確存儲所有時間，除非將系統(tǒng)設(shè)置為恒定的偏移時區(qū)，例如UTC或GMT-5。（我正在使用MySQL 5.0.45）
這是因為您無法在夏令時結(jié)束前的一個小時內(nèi)存儲任何時間。無論您如何輸入日期，每個日期函數(shù)都會將這些時間視為在切換后的一小時內(nèi)。
我的系統(tǒng)的時區(qū)為America/New_York。讓我們嘗試存儲1257051600（星期日，2009年11月1日06:00:00 +0100）。
這里使用專有的INTERVAL語法：
SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3599 SECOND); # 1257051599
SELECT UNIX_TIMESTAMP('2009-11-01 00:00:00' + INTERVAL 3600 SECOND); # 1257055200
SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 1 SECOND); # 1257051599
SELECT UNIX_TIMESTAMP('2009-11-01 01:00:00' - INTERVAL 0 SECOND); # 1257055200
甚至FROM_UNIXTIME()不會返回準確的時間。
SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(1257051599)); # 1257051599
SELECT UNIX_TIMESTAMP(FROM_UNIXTIME(1257051600)); # 1257055200
奇怪的是，DSTTIME 仍將在DST開始的“丟失”時間內(nèi)存儲和返回（僅以字符串形式?。r間（例如2009-03-08 02:59:59）。但是在任何MySQL函數(shù)中使用這些日期都是有風(fēng)險的：
SELECT UNIX_TIMESTAMP('2009-03-08 01:59:59'); # 1236495599
SELECT UNIX_TIMESTAMP('2009-03-08 02:00:00'); # 1236495600
# ...
SELECT UNIX_TIMESTAMP('2009-03-08 02:59:59'); # 1236495600
SELECT UNIX_TIMESTAMP('2009-03-08 03:00:00'); # 1236495600
要點：如果您需要在一年中的每個時間進行存儲和檢索，則有一些不受歡迎的選擇：
將系統(tǒng)時區(qū)設(shè)置為GMT +一些恒定的偏移量。例如UTC
將日期存儲為INT（如Aaron發(fā)現(xiàn)的，TIMESTAMP甚至不可靠）
假設(shè)DATETIME類型具有一些恒定的偏移時區(qū)。例如，如果您在使用America/New_York，請將日期轉(zhuǎn)換為MySQL之外的 GMT-5 ，然后將其存儲為DATETIME（事實證明這很重要：請參閱Aaron的回答）。然后，您必須格外小心地使用MySQL的日期/時間函數(shù)，因為某些函數(shù)假設(shè)您的值是系統(tǒng)時區(qū)，而其他函數(shù)（尤其是時間算術(shù)函數(shù)）則是“時區(qū)不可知的”（它們的行為就像是UTC一樣）。
Aaron和我懷疑自動生成的TIMESTAMP列也已損壞。兩者2009-11-01 01:30 -0400和2009-11-01 01:30 -0500將被存儲為模棱兩可2009-11-01 01:30。
侃侃爾雅
TA貢獻1801條經(jīng)驗 獲得超16個贊
由于我們使用TIMESTAMP帶有On UPDATE CURRENT_TIMESTAMP（即：）的列recordTimestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP來跟蹤更改的記錄和ETL到數(shù)據(jù)倉庫，所以這個線程讓我感到異常。
如果有人懷疑這種情況下的TIMESTAMP行為正確，并且可以通過將TIMESTAMPunix時間戳轉(zhuǎn)換為兩個相似的日期來區(qū)分它們：
select TestFact.*, UNIX_TIMESTAMP(recordTimestamp) from TestFact;
id recordTimestamp UNIX_TIMESTAMP(recordTimestamp)
1 2012-11-04 01:00:10.0 1352005210
2 2012-11-04 01:00:10.0 1352008810
添加回答
舉報
0/150
提交
取消