我目前正在開發一個應用程式，該應用程式不幸地要求處理復雜的本地化日期和時間。
作為一個簡單的例子，如果一個事件沒有在新加坡“今天”發生，這很容易表示：我們將日期存盤在 UTC、IANA 時區Asia/Singapore，也許還有給定時間戳（例如 08:00）的有效 UTC 偏移量，以便每次我們渲染它們時都不必查閱 IANA 資料庫。
如果您不熟悉，處理時區絕對是瘋狂的。我們不能僅僅假設新加坡總是 08:00：
- 夏令時可能會發生也可能不會發生，并且不同的語言環境在不同的日歷日開始和結束 DST，并且某些語言環境可能會偏移超過或少于一小時。
- 隨著時間的推移，DST和實際的 UTC 偏移量可能會發生變化。編造的例子：
- 作為一個虛構的例子，在 1971 年，DST 的開始日期和結束日期分別更改為 3 月 31 日和 10 月 1 日，而不是 2 月 27 日和 9 月 16 日。
- 1933 年，DST 偏移量從一小時改為一小時三十分鐘。
- 是的，這些事情確實會發生，IANA 資料庫在每個時區區域設定的基礎上覆寫它們，這就是為什么我們需要存盤給定日期時間的 UTC 偏移量和相關時區識別符號的原因。
- 更糟糕的是，當實際使用的日歷隨著時間的推移而發生變化時，語言環境在不同的時間采用了公歷/ISO 日歷，因此，他們不得不在過渡期間最多跳過幾周的時間。
- 一個實際的例子是 1918 年的蘇聯：在 1918 年 1 月 31 日之前，俄羅斯和其他國家使用儒略歷，與公歷相差十四天，所以從俄羅斯乘坐火車到歐洲只需一幾個小時可能會導致當前日期提前兩周。實際更改時，1 月 31 日是儒略歷的最后一天，而第二天是公歷的 2 月 14 日。
- 在符號中，此轉換之前的日期伴隨著舊式 (OS) 或新式 (NS)日期的說明符。
因此，為了正確表示這些轉換之前/之后的日期，我們必須存盤：
- 公歷/ISO 日歷中 UTC 格式的 RFC-3339 時間戳的日期時間。
- 與特定日期相關的最接近的命名時區，例如
Asia/Singapore：這意味著我們還必須收集一個帶有日期的位置，我們希望可以使用該位置來選擇這些命名時區之一。 - 根據指定時區的特定日期時間的 UTC 偏移量，例如
08:00. - 一個可選的其他日歷（我將其稱為日歷“投影”），它在相關日期時間期間在給定語言環境中使用，因此可以在兩個日歷中表示日期，以進一步澄清事情并提供更好的準確性。
如上所述，IANA 資料庫確實為每個時區提供了一個復雜的資料庫，以保持 UTC 偏移更改和 DST 更改的歷史準確時間表。在 Java 和其他編程語言中，日期時間庫使用此資料庫在 UTC 和指定時區的本地時間之間執行轉換。
然而，我需要的是一個類似的資料庫，它可以用來了解給定時區或地區使用的日歷，以便我可以為本地使用的日歷提供“投影”。我可以為此撰寫自己的系統，結合我能夠用來提供這些預測的資料，但眾所周知，時間非常艱難，我不想參與日歷的歷史研究來制作我自己的一套規則。
另一個問題似乎是為給定的一般地理位置找到正確的命名時區。在戰爭期間和之后，不同的地理位置易手，成為他們自己的國家等。1917年，俄羅斯的首都是彼得格勒（后來是列寧格勒，后來是圣彼得堡），但在某些時候變成了莫斯科。如果我有一個給定的一般地理區域（例如“基輔”或“烏克蘭”），我需要嘗試以某種方式將該城市與命名時區相關聯，我該怎么做？我是否對同一緯度內的任意城市最近的命名時區進行地理搜索？
總之：
- 是否存在一個 IANA 資料庫來跟蹤一個地理區域何時使用不同的日歷？
- 如果我有一個給定城市或國家的地理區域，我如何確定要使用哪個命名時區？
uj5u.com熱心網友回復：
提醒讀者有關定義：
- 與 UTC的偏移量僅比 UTC 提前或落后幾個小時-分鐘-秒。現代協議通常指的是正數在 UTC 之前，負數在 UTC 之后。但是有些協議會做相反的事情，所以要小心。
- 時區更多。時區是由政治家決定的特定地區人民使用的偏移量的過去、現在和未來變化的命名歷史。
這樣就不必每次渲染它們時都查閱 IANA 資料庫。
當心：政客改變時區規則。他們這樣做的頻率令人驚訝，更令人驚訝的是幾乎沒有預先警告。這種情況發生在不同的文化和大陸上，各種各樣的政治家都表現出喜歡玩弄時區規則的傾向。
我建議不要預先計算與 UTC 的偏移量。我建議在 UTC 中存盤一個時刻，即時間線上的一個特定點（與 UTC 的偏移量為零小時-分鐘-秒）。為了向用戶展示，或者在業務邏輯需要的地方，動態調整到一個時區。
如果您不熟悉，處理時區絕對是瘋狂的。
不是真的“瘋狂”，但是是的，非常棘手、違反直覺且容易出錯。
我們不能僅僅假設新加坡總是 08:00
你不能。正如我上面所說，偏移量和時區是政治時間，由善變的政客定義。
夏令時可能會發生也可能不會發生，并且不同的語言環境在不同的日歷日開始和結束 DST，并且某些語言環境可能會偏移超過或少于一小時。
是的，政客們經常更改夏令時 (DST)的開始和結束日期。
是的，這些事情確實會發生
是的，政客們發明了各種各樣的調整，有時非常古怪和毫無意義。
最新的時尚正在進入 DST 并且永不停止，一個永恒的 DST。因此，太陽再也不會在中午直接出現在頭頂——違反了中午的定義。
DST 偏移量從一小時更改為一小時三十分鐘。
政客們可以在他們的時區內隨意改變當前的偏移量，以他們喜歡的任意數量，任意數量的小時-分鐘-秒。
語言環境在不同時間采用公歷/ISO 日歷
在談論日期時間處理時避免使用“語言環境”這個詞。這個詞在本地化作業中具有特定的含義。許多開發人員錯誤地認為語言環境和時區是相關的，但事實并非如此。時區與特定政治家控制下的法律管轄區相關聯；語言環境不是。
不要將公歷與ISO 8601日歷混為一談。例如，ISO 8601 規定周從星期一開始。各種公歷實作可能使用不同的星期幾。此外，這意味著每個日歷系統下的周數不同。
據我所知，各個時區在不同的時間點采用日歷系統這一事實并不是什么大問題。這些更改在 IANA 資料庫（也稱為tz 資料庫，以前稱為Olson 資料庫）中進行了說明。但我可能錯了，因為我只對當代進行日期時間處理。
?? 注意：tz 資料庫通常僅在 1970 年左右才準確。甚至在最近幾十年中，也發生了一些錯誤和遺漏。
令人驚訝的是，政府官僚機構和學術歷史學家忽略了收集時區變化的完整記錄。只有在過去的幾十年里，才有組織的記錄被拼湊在一起。
datetime 作為 RFC-3339 時間戳
我建議您避免使用RFC 3339。該檔案只是 ISO 8601 標準的自我宣告的“簡介”。但是 RFC 3339 故意破壞了 ISO 8601 的一些元素。
例如，其中一項破壞規則是允許負偏移量為零，-00:00此外還允許 00:00. 他們的邏輯讓我無法理解。根據 ISO 8601，a-00:00是被禁止的。
堅持 ISO 8601。
與特定日期相關的最接近的命名時區，例如亞洲/新加坡：這意味著我們還必須收集一個位置
不，位置不相關。意圖和背景是相關的，法律管轄權是相關的。位置不一定表示相關時區。
例如，坐在巴黎（Europe/Paris時區）的兩個商務人士可能正在簽署一份合同，其法律條款在加拿大使用America/Edmonton時區定義。兩個不同的日期可能在起作用，歐洲的“明天”同時是美洲的“昨天”。
另一個問題似乎是為給定的一般地理位置找到正確的命名時區
同樣，時區是由政治家決定的，而不是由地理決定的。如果當地政客定義了與更大區域/管轄區不同的偏移量，則會創建一個細分的時區名稱。請參閱Wikipedia中的 tz 資料庫時區串列（順便說一下，不一定更新為最新資訊）。以美國印第安納州為例：
- 美國/印第安納州/印第安納波利斯
- 美國/印第安納州/諾克斯
- 美國/印第安納州/馬倫戈
- 美國/印第安納州/圣彼得堡
- 美國/印第安納州/Tell_City
- 美國/印第安納州/Vevay
- 美國/印第安納州/文森斯
- 美國/印第安納州/Winamac
是否存在一個 IANA 資料庫來跟蹤一個地理區域何時使用不同的日歷？
我沒有聽說過。
如果我有一個給定城市或國家的地理區域，我如何確定要使用哪個命名時區？
如果有任何這樣的查找，我會感到驚訝。正如我試圖解釋的那樣，時區是管轄權的，而不是地理的。對于空間中的任何點（地理），您首先必須確定在您感興趣的那一刻，哪個司法管轄區擁有控制權。然后您需要將該管轄區映射到時區名稱，這是我從未見過的映射。
最后，我想知道你的問題對于迄今為止的歷史時刻是否真的沒有實際意義。1917年的俄羅斯，你真的關心時區之間的仔細調整嗎？我承認時區調整在當代至關重要，例如確定合同何時簽署和生效，正如我上面提到的。但就目前而言，我無法想象它的實際用途。
正如我所說，我們只有自 1970 年以來才有過不錯的時區歷史，甚至只是勉強。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/510305.html
標籤：日期约会时间时间日历时区