夏令時和時區(qū)最佳實踐我希望能夠?qū)⑦@個問題及其答案作為處理夏令時的權(quán)威指南，特別是處理實際的變更問題。如果您有任何要添加的內(nèi)容，請執(zhí)行此操作許多系統(tǒng)依賴于保持準確的時間，問題在于由于夏令時改變時間 - 向前或向后移動時鐘。例如，在訂單獲取系統(tǒng)中有一個業(yè)務規(guī)則取決于訂單的時間 - 如果時鐘發(fā)生變化，規(guī)則可能不那么明確。如何保持訂單的時間？當然有無數(shù)的場景 - 這只是一個說明性的場景。你是如何處理夏令時問題的？您的解決方案中有哪些假設？（在這里尋找背景）同樣重要的是，如果不是這樣的話：你嘗試了哪些不起作用？為什么不起作用？我會對編程，操作系統(tǒng)，數(shù)據(jù)持久性和該問題的其他相關方面感興趣。一般答案很好，但我也希望看到細節(jié)，特別是如果它們只在一個平臺上可用。
4 回答
largeQ
TA貢獻2039條經(jīng)驗 獲得超8個贊
我不確定我能在上面的答案中添加什么，但這里有幾點我：
時代的類型
您應該考慮四種不同的時間：
活動時間：例如，國際體育賽事發(fā)生的時間，或加冕/死亡/等等。這取決于事件的時區(qū)而不是觀眾的時區(qū)。
電視時間：例如，特定的電視節(jié)目在當?shù)貢r間晚上9點播出。在考慮在您的網(wǎng)站上發(fā)布結(jié)果（比如說“美國偶像”）時很重要
相對時間：例如：這個問題在21小時內(nèi)有一個開放的賞金。這很容易顯示
重復時間：例如：即使DST發(fā)生變化，每周一晚上9點都有電視節(jié)目。
還有歷史/交替時間。這些都很煩人，因為它們可能無法映射回標準時間。例如：朱利安日期，日期根據(jù)土星的農(nóng)歷，克林貢日歷。
以UTC格式存儲開始/結(jié)束時間戳效果很好。對于1，您需要與事件一起存儲的事件時區(qū)名稱+偏移量。對于2，您需要為每個區(qū)域存儲本地時間標識符，并為每個查看器存儲本地時區(qū)名稱+偏移量（如果您處于緊縮狀態(tài)，則可以從IP中獲取此值）。對于3，以UTC秒存儲，不需要時區(qū)。4是1或2的特殊情況，具體取決于它是全局還是本地事件，但您還需要存儲在時間戳中創(chuàng)建的內(nèi)容，以便您可以判斷在創(chuàng)建此事件之前或之后是否更改了時區(qū)定義。如果您需要顯示歷史數(shù)據(jù)，這是必要的。
存放時間
始終以UTC格式存儲時間
轉(zhuǎn)換為顯示的本地時間（本地由查看數(shù)據(jù)的用戶定義）
存儲時區(qū)時，需要名稱，時間戳和偏移量。這是必需的，因為政府有時會改變其時區(qū)的含義（例如：美國政府更改了DST日期），并且您的應用程序需要優(yōu)雅地處理事情...例如：DST規(guī)則之前和之后LOST劇集的確切時間戳顯示改變。
偏移和名稱
以上的一個例子是：
足球世界杯決賽比賽于2010年7月11日19:00 UTC在南非（UTC + 2 - SAST）舉行。
有了這些信息，我們可以歷史地確定2010年WCS決賽發(fā)生的確切時間，即使南非時區(qū)定義發(fā)生變化，并且能夠在查詢數(shù)據(jù)庫時向當?shù)貢r區(qū)的觀眾顯示。
系統(tǒng)時間
您還需要使您的操作系統(tǒng)，數(shù)據(jù)庫和應用程序tzdata文件保持同步，彼此之間以及與世界其他地方同步，并在升級時進行廣泛測試。您依賴的第三方應用程序未正確處理TZ更改并非聞所未聞。
確保硬件時鐘設置為UTC，如果您在世界各地運行服務器，請確保其操作系統(tǒng)也配置為使用UTC。當您需要從多個時區(qū)的服務器復制每小時輪換的apache日志文件時，這一點就變得很明顯了。按文件名對它們進行排序僅在所有文件都使用相同的時區(qū)命名時才有效。這也意味著當您從一個框轉(zhuǎn)到另一個框并且需要比較時間戳時，您不必在頭腦中進行日期數(shù)學計算。
此外，在所有框上運行ntpd。
客戶端
永遠不要相信從客戶端計算機獲得的時間戳有效。例如，Date：HTTP標頭或javascript Date.getTime()調(diào)用。當用作不透明標識符時，或者在同一客戶端上的單個會話期間進行日期數(shù)學運算時，這些都很好，但不要嘗試將這些值與服務器上的內(nèi)容交叉引用。您的客戶端不運行NTP，并且可能不一定有可用于其BIOS時鐘的電池。
瑣事
最后，政府有時會做很奇怪的事情：
從1909-05-01到1937-06-30，荷蘭的標準時間恰好是UTC的19分和32.13秒。使用HH：MM格式無法準確表示此時區(qū)。
好的，我想我已經(jīng)完成了。
繁花如伊
TA貢獻2012條經(jīng)驗 獲得超12個贊
明確關注點的架構(gòu)分離 - 準確了解哪個層與用戶交互，并且必須更改規(guī)范表示（UTC）的日期時間。非UTC日期時間是表示（遵循用戶本地時區(qū)），UTC時間是模型（對于后端和中間層保持唯一）。
另外，決定你的實際觀眾是什么，你不需要服務什么，以及你在哪里畫線。不要觸摸異國情調(diào)的日歷，除非您實際上有重要的客戶，然后考慮僅針對該區(qū)域的單獨的面向用戶的服務器。
如果您可以獲取并維護用戶的位置，請使用位置進行系統(tǒng)的日期時間轉(zhuǎn)換（例如.NET文化或SQL表），但如果日期時間對您的用戶至關重要，則為最終用戶提供選擇替代的方法。
如果涉及歷史審計義務（比如確切知道2月前Jo在AZ支付賬單的時間是9月），那么保留UTC和當?shù)貢r間進行記錄（您的轉(zhuǎn)換表將在一段時間內(nèi)發(fā)生變化）。
為批量生成的數(shù)據(jù)定義時間參考時區(qū) - 如文件，Web服務等。假設East Coast公司在CA中有數(shù)據(jù)中心 - 您需要詢問并知道他們使用什么作為標準而不是假設其中一個。
不要信任嵌入在日期時間的文本表示中的時區(qū)偏移，并且不接受解析和遵循它們。而是始終要求必須明確定義時區(qū)和/或參考區(qū)域。您可以輕松地接收PST偏移的時間，但時間實際上是EST，因為這是客戶端的參考時間，而記錄只是在PST中的服務器上導出。
添加回答
舉報
0/150
提交
取消