IANA 時區資料庫到底是什麼
如果你曾在軟體開發中處理過日期與時間，那麼無論你是否意識到，你早已依賴過 IANA 時區資料庫。它有多個名稱——tz 資料庫、tzdata、Olson 資料庫或 zoneinfo——但這些都指向同一個東西：一個協作式、免費開放的全球時區及其規則目錄。
「目錄」這個詞其實低估了它的價值。這個資料庫不僅僅列出哪些地區位於哪個 UTC 偏移量。它記錄了每個地區完整的民用時間史——每一次偏移變更、每一次夏令時轉換、每一次戰時時鐘調整，以及每一條預定的未來規則——在許多情況下，甚至可以追溯到 19 世紀中葉，當時地方平均時間開始被標準化時區取代。當你的日曆應用程式正確顯示 1985 年的一場會議比今天相同的掛鐘時間早了一小時時，這就是 tz 資料庫在發揮作用。
它是基於文字的、人類可讀的，而且體積很小。你電腦上搭載的編譯二進位形式只有幾 MB。然而，它編碼了運算領域中最默默無聞卻又最複雜的資料集之一。
簡史
這個專案始於 1980 年代，由 Arthur David Olson 發起，他組裝了第一個版本並將其託管在美國國家衛生院的伺服器上。幾十年來，它主要透過一個公共郵件列表協調的志願者努力來維護，這也是為什麼較舊的名稱「Olson 資料庫」仍然出現在文件中。
Paul Eggert 接任主要編輯，並長期擔任該專案的協調人。他編寫的配套 theory.html 文件以及一絲不苟的提交歷史，使這個資料庫既是技術參考，也是歷史參考。
2011 年，在一場短暫但令人擔憂的歷史資料法律糾紛之後，管理權移交給了網際網路號碼分配局 (IANA)，也就是協調其他核心網路資源的同一個機構。IANA 現在發布官方版本，這就是為什麼「IANA 時區資料庫」已成為標準名稱。實際工作仍由同一個貢獻者社群完成；IANA 提供了一個機構歸屬和穩定的發布點。
命名慣例：地區/地點
該資料庫最顯著的特點之一是其命名時區的方式。它不使用國家名稱或原始偏移量，而是採用 地區/地點 格式，幾乎總是錨定於一個代表性城市：
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
「地區」通常是一個大陸或海洋（America、Europe、Asia、Pacific），而「地點」則是該時區內一個知名的城市。這種選擇乍看之下很奇怪，但了解其背後的原因後就會明白。
城市是穩定的；政治邊界和偏移量則不然。 國家會分裂、合併、改名，並改變它們的時鐘。相比之下，城市是一個固定的地理點，擁有連續的時間記錄歷史。將時區命名為 America/New_York 而不是「美國東部時間」或「UTC-5」，意味著即使附加在其上的規則發生變化，這個識別碼仍然有效。
該資料庫也刻意避免使用國家名稱，以避開政治爭議，並且因為單一國家通常包含多個時區——美國就有十幾個。它在每個不同的時區中選擇人口最多或歷史意義最重大的城市作為中立標籤。當兩個地區自 1970 年以來共享完全相同的時鐘歷史時，它們共享一個時區；一旦它們的歷史出現分歧，就會獲得單獨的條目。
為什麼原始偏移量不夠用
初學者常見的直覺是將時間儲存為「UTC+5:30」就完事了。這對於單一時間點有效，但當你需要推論未來或重複發生的事件時，它就失效了，因為偏移量並非一個地方的靜態屬性。它們是政府不斷且經常突然改變的規則的輸出結果。
考慮幾個資料庫必須吸收的真實案例：
- 薩摩亞完全跳過了 2011 年 12 月 30 日。 為了使其工作日與澳洲和紐西蘭（而非美國）保持一致，薩摩亞跨越了國際換日線，從 UTC-11 移動到 UTC+13。對於島上的任何人來說，那個星期五根本不存在。
- 各國在幾乎沒有預警的情況下廢除、採用或重新安排夏令時間。 歐盟一直在辯論是否終止夏令時間；幾個國家和美國各州在近幾十年來改變了它們的夏令時間規則。土耳其、俄羅斯和其他國家則直接改變了它們的標準偏移量。
- 夏令時間的開始和結束日期會變動。 美國在 2007 年改變了其夏令時間的邊界。任何硬編碼舊規則的系統每年都會在數週內默默地產生錯誤的時間。
如果你只儲存偏移量，你無法回答「明年 11 月 15 日聖地亞哥的當地時間是什麼？」這個問題——因為答案取決於可能尚未最終確定的規則。儲存時區識別碼（America/Santiago）加上資料庫，可以讓軟體為任何過去或未來的時刻計算出正確的偏移量，並在規則改變時自動重新計算。
這就是核心價值主張：tz 資料庫將一個地方的身份與決定其時鐘的不斷變化的規則分離開來。
如何維護
維護工作是公開進行的。提議的變更——新的夏令時間規則、修正的歷史日期、政府公告——會在公共的 tz 郵件列表上討論，貢獻者會引用官方公報、新聞報導和政府法令作為證據。準確性受到高度重視；特別是對歷史資料的更改，會根據原始來源進行審查。
版本使用年份和字母進行標記：2024a、2024b、2024c，以此類推。數字是年份；字母隨著該年度的每次發布而遞增。由於政府按照自己不可預測的時間表宣布時鐘變更，因此沒有固定的發布節奏——平靜的一年可能只有兩次發布，而政治動盪的一年則會有多次發布。系統需要及時更新，因為過時的資料庫可能意味著在規則變更生效後顯示錯誤的時間。
誰依賴它
幾乎所有東西。
- 作業系統。 Linux 發行版將
tzdata作為核心套件提供。macOS 從同一來源獲取其時區資料。Windows 出於遺留原因使用自己基於登錄檔的時區，但透過 ICU 函式庫和現代 API 暴露 IANA 時區。 - 程式語言。 實際上每個成熟的日期/時間函式庫都會讀取或捆綁 tz 資料庫：Python 的
zoneinfo、Java 的java.time、ICU 專案、PostgreSQL、透過 ICU 的 JavaScript 引擎、Ruby、PHP 等等。 - 應用程式。 日曆、預訂系統、金融交易平台、日誌分析工具和排程服務都依賴它，而開發人員通常不會想到這一點。
這種普遍性正是該資料庫如此重要的原因。一個單一的、共享的、精心維護的真相來源，意味著在一個系統中安排的會議，能夠在另一個系統中正確顯示，跨越作業系統和語言，無論是幾十年前還是未來。
如果你想探索這些時區本身，請瀏覽完整的 IANA 時區 列表，或在我們的 所有時區 目錄中查看它們如何映射到全球。
常見問題
tz 資料庫與 tzdata、zoneinfo 和 Olson 資料庫相同嗎？
是的。這些都是同一個專案的名稱。「tzdata」通常指打包給作業系統的資料檔案，「zoneinfo」指編譯後的二進位目錄，而「Olson 資料庫」是根據創始人 Arthur David Olson 命名的較舊歷史名稱。如今，官方名稱是 IANA 時區資料庫。
資料庫多久更新一次？
沒有固定的時間表。發布是由現實世界的事件觸發的——政府改變其夏令時間規則或標準偏移量，或是對歷史資料的修正。有些年份只有一次發布；其他年份則有多次。每個發布都命名為 2024a、2024b，字母在一年中遞增。
為什麼它用 America/New_York 這樣的城市來命名時區？
城市在地理上是固定的，並且有連續的時間記錄歷史，而國家、邊界和偏移量會隨著時間而變化。使用一個代表性城市為每個時區提供了一個穩定的、政治中立的識別碼，即使底層的夏令時間或偏移量規則發生變化，該識別碼仍然有效。
我可以只儲存 UTC 偏移量而不是時區名稱嗎？
僅適用於單一固定的時間點。對於未來或重複發生的事件，你應該儲存時區識別碼，因為偏移量會隨著夏令時間和政府決策而變化。時區名稱加上資料庫可以讓軟體自動為任何日期計算出正確的偏移量。
現在誰在運行這個專案？
它由 IANA 發布（IANA 於 2011 年接管管理權），並由 Paul Eggert 與一個貢獻者社群在公共 tz 郵件列表上協調。技術工作仍然是一項協作、志願者驅動的努力。