我錯過的最昂貴的會議安排正確。倫敦有人輸入&報價;下午 3 點,上午 10 點 yours"在紐約向我發出日曆邀請,他們在二月寫的時候確實如此。電話是在 3 月 12 日。美國已經把時鐘提前了上週日;英國沒有,而且也不會再持續三週。倫敦和紐約之間的差距通常是五個小時,那週是四個小時--所以倫敦下午 3 點對我來說就是上午 11 點,而不是上午 10 點。我提前一個小時加入了一個空房間,放棄了,完全錯過了電話。
春季的三週窗口期和秋季的一週窗口期並不是一個邊緣案例。這種情況每年都會發生,它會吸引那些精通算術的人,因為算術不是問題。問題是&引用;倫敦比紐約提前五個小時&引用;這不是關於兩個城市的事實。這是關於兩個城市的事實 在特定日期,當你寫下它但沒有附加日期的那一刻,你就創建了一個錯誤。
時區不是偏移量。它是一組規則,當您立即提供偏移量時會產生偏移量。這些規則發生變化:各國採用夏令時,放棄夏令時,改變其標準偏移量,或在三週內宣布永久變化'注意。這就是原因 時區轉換器 上 工具。dev 切勿在任何地方儲存偏移量。它問 伊安娜 時區資料庫 - 已經位於瀏覽器內的資料庫 - 您轉換的確切時刻的偏移量是多少,並且每隔一個時刻它都會再次詢問。
TL;DR: 兩個區域之間的差距取決於日期,因為國家之間的夏令時過渡並不一致。這 時區轉換器 解析您輸入的特定時刻透過 IANA 資料庫的每次偏移量,顯示 UTC 偏移量和符號差,處理半小時和四分之一小時區域,並將相同瞬間分佈在會議規劃條中的多個城市。它完全在您的瀏覽器中運行。
主要特點
每分鐘解決偏移量,從不進行硬編碼
該工具中的每個偏移量都是透過將您的瞬間格式化為目標區域並讀取掛鐘來計算的。單一設計決策意味著夏令時、歷史規則變更以及透過政府法令調整偏移量的國家/地區都由相同的程式碼路徑處理。沒有需要維護的偏移表,也沒有需要陳舊的表。轉換一月份柏林和芝加哥之間的會議和七月的同一次會議,該工具兩次都會正確地為您提供 7 小時的間隔 - 但在三月下旬轉換一次,它會正確地為您提供 6 小時的間隔。
超過 50 個 IANA 策劃區
選擇器列出了人們實際安排的城市,按地區分組,標有他們的國家/地區,並顯示在完整的 IANA 標識符旁邊。最後一部分比看起來更重要: Asia/Kolkata 是您貼上到 cron 表達式 Postgres 中的字串 AT TIME ZONE 子句,或 Python ZoneInfo 構造函數。閱讀並引用;加爾各答,印度&引用;和複製 Asia/Kolkata 是兩個不同的工作,而該工具可以同時完成這兩個工作。
會議策劃帶
在轉換下方,您新增的每個區域都會獲得一排跨越瞬間視窗的小時儲存格。工作時間(當地時間 09:00 至 17:59)帶有陰影,早晚時間分別標記,任何位於不同日曆日的儲存格都帶有 +1d 或者 -1d 徽章。同時找到舊金山、倫敦和雪梨文明的一小時是一個難題--連環畫使其成為視覺上的而不是算術上的。
半小時和四分之一小時區域被視為正常
印度是 UTC+05:30。尼泊爾是 UTC+05:45。阿德萊德冬季為 UTC+09:30,夏季為 UTC+10:30。查塔姆群島為 UTC+12:45。大約佔世界的五分之一'人口生活在一個不是整小時的偏移量上,任何假設其他情況的工具對數億人來說都是錯誤的。此處的偏移量以分鐘為單位儲存和顯示。
顯示您輸入日期的縮寫
轉換的每一側都顯示當時有效的區域縮寫 - EST 或 EDT、GMT 或 BST、AEST 或 AEDT。這是查看您落在過渡哪一側的最快方法。如果您輸入了三月日期並且工具顯示 EDT,則時鐘已更改。如果它顯示 EST,則他們沒有。
完全是客戶端
每個計算都在瀏覽器中的 JavaScript 中運行,使用 Intl API 和隨引擎一起附帶的時區資料庫。您輸入的任何內容都不會上傳,不會記錄任何內容,一旦頁面加載,轉換器就會在沒有網路連線的情況下繼續工作。這也意味著結果會在您更改欄位時更新,因為沒有往返等待。
如何使用時區轉換器
步驟 1:設定來源區域、日期和時間
選擇您正在轉換的城市 從,然後輸入與時鐘讀數完全相同的日期和時間。時間欄位採用 24 小時值,因此下午 3 點為 15:00. 如果您想要當前時刻而不是假設時刻,請按 現在- 它載入來源區域中看到的當前日期和時間,該日期不一定與您自己牆上的日期相同。
第二步:選擇目標區域
選擇您想要答案的城市。轉換後的日期、時間和 12 小時讀數以及適用於該特定日期的 UTC 偏移量和縮寫立即出現。注意 日期 可以更改:紐約週一 21:00 是達卡週二 07:00,該工具顯示新日期,而不是悄悄地讓您自行解決。
第三步:讀取偏移量和間隙
在每一側下方,您都可以獲得偏移量 UTC±HH:MM 形式和區域縮寫。在它們之間,工具用文字說明關係 - "達卡比紐約提前 10 小時" - 該日期的正確值,而不是記憶的平均值。使用交換按鈕反轉方向;它保持不變 瞬間 並翻轉你要進入的哪一側,這幾乎就是你一直想要的。
第四步:建造會議跑道
將每個參與者's 區域新增至規劃器。每一行都會顯示該區域中的相同瞬間以及周圍的時間,並顯示工作時間。提前或稍後滑動來源時間並觀看陰影移動。當陰影單元格在每一行中排列時,您就找到了您的插槽。
第 5 步:複製結果
複製轉換後的時間,或完整的表達式 - Sun, Mar 12, 2026 09:00 EDT (America/New_York) = Sun, Mar 12, 2026 13:00 GMT (Europe/London)- 並將其貼到日曆邀請中。用縮寫寫兩面是不重複我在倫敦的錯誤的最有效的習慣。
時區轉換的實際工作原理
天真的心理模型是每個區域都有一個附加的數字,轉換就是減法。該模型在大多數情況下產生正確答案的方式是錯誤的,這是最糟糕的可能失敗模式。
正確的模型有三層。
第一層:瞬間。 一切之下都是通用時間線上的一個點--一個紀元時間戳,自 1970-01-01T00:00:00Z 以來的秒數。瞬間是明確的。地球上的每個人都同時經歷同一瞬間,無論他們的時鐘說什麼。
第二層:偏移量。 偏移量是添加到 UTC 以獲得本地掛鐘時間的簽名分鐘數。 UTC-04:00 是一個偏移量。它是一個 結果,不是某個地方的財產。
第三層:區域。 區域是一組命名的規則 - America/New_York- 將瞬間映射到偏移量。這是人們崩潰到第二層的層,而這種崩潰幾乎是有史以來每個時區錯誤的來源。
所以轉換不是 localB = localA + delta. 它是:
instant = resolve(wallClockA, zoneA) // rules of A, applied to that reading
wallClockB = render(instant, zoneB) // rules of B, applied to that instant
兩個規則查找,中間一個。該工具正是這樣做的。要立即解析某個區域的偏移量,它將瞬間格式化為該區域,讀回年份、月份、日期、小時、分鐘和秒,將這些欄位視為 UTC,並減去真實瞬間。差異是直接從引擎' 的 IANA 資料庫副本的偏移量(以分鐘為單位)。
向另一個方向 - 從掛鐘讀數到瞬間 - 有一個先有雞還是先有蛋的問題,因為您需要偏移量來找到瞬間,而瞬間則需要找到偏移量。一旦使用樸素偏移,工具就會進行猜測,檢查猜測是否落在過渡的另一側,如果落地,則進行修正。兩次查找,總是終止,跨越 DST 邊界進行修正。
IANA 時區資料庫
一切都依賴的資料庫由 IANA 維護,通常仍稱為 "奧爾森資料庫&報價;以 Arthur David Olson 命名,他於 20 世紀 80 年代開始。它包含在每個作業系統、每個瀏覽器、每個 JVM 和每個 Python 安裝中,並且每年都會更新幾次,因為政府不斷改變主意。
它的標識符採用以下形式 Area/Location: America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney. 該地點是一個代表性城市,而不是一個政治主張 - America/New_York 印第安納州覆蓋了整個美國東部地區,眾所周知,印第安納州需要十幾個自己的標識符,因為幾十年來,各縣在是否實施夏令時方面存在分歧。
資料庫儲存的內容不是每個區域的單一偏移量,而是完整的規則歷史記錄。它知道烏克蘭's Europe/Kyiv 是 Europe/Kiev 直到2022年更新拼字。它知道埃及在2014年放棄夏令時後,於2023年重新引入了夏令時。它知道薩摩亞在跳過國際日期變更線時完全跳過了2011年12月30日。這段歷史就是為什麼將同一對城市的日期轉換為 2015 年和 2025 年可以合法地產生不同的答案,以及為什麼硬編碼偏移的工具是掩蓋過去的工具。
對於任何編寫軟體的人來說,實際後果是: 在 UTC 中儲存瞬間,將 user's 區域儲存為 IANA 標識符,並且僅在顯示層進行轉換。 切勿儲存偏移量。偏移量是規則的渲染,規則會改變。如果您直接使用紀元值,則 時間戳轉換器 是將它們作為日期讀回的配套工具。
UTC 偏移量、縮寫和區域名稱:使用
這三件事總是令人困惑,而且不可互換。
| 形式 | 例子 | 穩定的? | 獨特的? | 用它來 |
|---|---|---|---|---|
| IANA 區域名稱 | America/New_York |
是的,跨越夏令時 | 是的 | 儲存、程式碼、配置、API |
| UTC 偏移量 | UTC-04:00 |
不,隨夏令時變化 | 不 | 顯示器、附有即時連接的電線格式 |
| 縮寫 | EDT |
不,隨夏令時變化 | 不 | 僅面向人體的顯示 |
兇手就是最後一欄。縮寫並不是唯一的。 CST 指美國中部標準時間、中國標準時間、古巴標準時間-三種不同的偏移量,一串。 IST 指印度標準時間、愛爾蘭標準時間及以色列標準時間。 BST 指英國夏令時,也稱為布干維爾標準時間。如果系統收到 CST 透過電線並且必須猜測,它會對某人猜測錯誤。
偏移形式明確但不穩定: UTC+01:00 正確辨識即時'渲染,但它不是一個區域,您無法使用它進行計算 下一個 星期二's 渲染,因為下週二可能會落在過渡的另一邊。
只有 IANA 名稱帶有規則。這是三個你應該堅持下去的唯一一個。
為什麼兩個城市之間的差距不斷擴大
夏令時是原因,而夏令時如此嚴重的原因是各國沒有同步過渡。
- 美國 三月的第二個星期日向前湧動,十一月的第一個星期日則回落。
- 歐盟 三月的最後一個星期日向前湧動,十月的最後一個星期日則回落。
- 澳洲,在南半球,情況恰恰相反:十月向前,四月向後--而昆士蘭州、西澳大利亞州和北領地根本不這樣做。
- 印度、中國、日本、非洲大部分地區和亞洲大部分地區 任何時候都不要觀察它。
將它們對齊,您會看到重疊窗口,其中通常的間隙完全錯誤:
| 時期 | 紐約時鐘 | 倫敦時鐘 | 間隙 |
|---|---|---|---|
| 冬天的大部分時間 | 美國東部時間 (UTC -05:00) | 格林威治標準時間 (UTC+00:00) | 5小時 |
| 三月第二個星期日 → 三月最後一個星期日 | 美國東部時間 (UTC-04:00) | 格林威治標準時間 (UTC+00:00) | 4小時 |
| 夏季的大部分時間 | 美國東部時間 (UTC-04:00) | 英國夏令時 (UTC+01:00) | 5小時 |
| 十月的最後一個星期日 → 十一月的第一個星期日 | 美國東部時間 (UTC-04:00) | 格林威治標準時間 (UTC+00:00) | 4小時 |
每年有兩個窗口 - 春季大約三週,秋季大約一周 - 其中每個窗口 "we'總是相隔五個小時並引用;日曆中的假設相差一個小時。而這只是一對城市。添加悉尼,其過渡方向相反,一年中不同間隙值的數量迅速攀升。
這些轉變本身又造成了兩個值得命名的危險。當時鐘向前彈起時,當地時間一小時 不存在- 紐約過渡之夜 02:30 並不是真正的閱讀。當時鐘倒退時,當地時間一小時 發生了兩次,裸露的掛鐘讀數確實是不明確的。轉換器將不存在的時間解析為轉換後的瞬間,將不明確的時間解析為第一次出現,這是大多數日曆軟體遵循的約定。這不是唯一可以辯護的選擇,但它是產生最少驚喜的選擇。
常用案例
透過分散式團隊安排會議。 顯而易見的一個,也是規劃者地帶存在的那個。三個或多個區域是心算可靠失敗的地方,特別是當其中一個區域處於半小時偏移或位於南半球時。
撰寫日曆邀請和公告。 始終用區域說明時間,始終給出至少兩個渲染,並且更喜歡 IANA 名稱或完全限定的縮寫而不是 "我的時間和報價; &引用; 14:00 UTC(美國東部時間 10:00 /美國標準時間 19:30)"是明確的。 &引用;2pm&引用;是拋硬幣。
調試日誌中的時間戳記。 伺服器登入 UTC,客戶報告本地時間的事件,在找到請求之前需要協調兩者。將客戶's 報告轉換為 UTC,然後進行搜尋。如果日誌是紀元值而不是 ISO 字串,請將它們運行到 時間戳轉換器 首先。
安排 cron 作業和背景工作。 設定為 UTC 的伺服器上的 cron 表達式不會隨使用者 #39 轉移;夏令時更改,這通常是您想要的 - 如果作業打算在夏令時觀察國家/地區的客戶本地 09:00 運行,有時恰好是您不想要的。在提交時間表之前計算出兩個讀數;這 克朗解析器 會告訴你你的表達實際上意味著什麼。
計劃旅行並與家人通話。 每個機場的出發和到達時間始終以當地時間給出,這意味著航班'在您將兩端轉換為同一區域之前,明顯的持續時間是無稽之談。 14 小時航班,該航班 "出發前到達並報價;只是一個日期變更線交叉。
協調發射、部署和禁運。 任何跨多個市場有硬截止值的東西都需要一個瞬間,以 UTC 表示,並為每個區域附加本地渲染。如果您計算的是該時刻還剩多少天而不是時鐘讀數,則 日期差計算器 是工作流程的另一半。
問號
如何將 EST 轉換為 IST？
選擇 America/New_York 作為來源和 Asia/Kolkata 作為目標。印度在東部標準時間比紐約早 10 小時 30 分鐘,在東部夏令時比紐約早 9 小時 30 分鐘,因為印度不實施夏令時,美國也實施夏令時。這種變化的差距正是您應該根據日期進行轉換而不是記住單一數字的原因。
EST和EDT有什麼不同？
EST(東部標準時間)為 UTC -05:00,適用於冬季。 EDT(東部夏令時間)為 UTC -04:00,適用於 3 月的第二個星期日至 11 月的第一個星期日。 &引用;東部時間和引用;或 ET 是總稱,表示目前有效的。在文件和程式碼中,首選 IANA 識別碼 America/New_York,這是全年明確的。
這台轉換器能否處理夏令時間？
是的,它是針對您輸入的日期而不是今天進行的。每個區域和#39;偏移量在您轉換的特定時刻透過 IANA 時區資料庫解決,因此 3 月 1 日的會議和 3 月 15 日紐約和倫敦之間的同一會議將分別正確顯示 5 小時間隙和 4 小時間隙 -美國比歐洲提前三週提前時鐘。
什麼是 IANA 時區標識符？
這是一個像這樣的名字 America/New_York, Europe/London,或者 Asia/Kolkata 參考資料集取自 IANA 時區資料庫,不僅記錄當前偏移量,還記錄每個歷史規則變更。識別碼是區域/位置對,它們是軟體中命名區域的唯一安全方法,因為 CST 等縮寫不明確 - 美國中部標準、中國標準和古巴標準都聲稱這一點。
為什麼有些時區有 30 或 45 分鐘的偏移量？
因為區域是政治性的,而不是幾何性的。印度決定採用 UTC+05:30,在一個時鐘上運行一個廣闊的國家。尼泊爾選擇 UTC+05:45 比印度早 15 分鐘。阿德萊德為 UTC+09:30,查塔姆群島為 UTC+12:45。對於世界上大約五分之一的人口來說,任何假設偏移量為整小時的代碼最終都會出錯。#39;s 人口。
什麼是 UTC，它與 GMT 有何不同？
UTC(協調世界時)是原子鐘標準,每個區域都被定義為偏移量。 GMT(格林威治標準時間)是冬季恰好等於 UTC+00:00 的時區 - 英國在夏季移至 BST (UTC+01:00),所以"GMT"和"倫敦時間&報價;全年都不一樣。儲存並比較 UTC 中的瞬間;轉換為僅用於顯示的區域。
世界上有多少時區？
理論上有 24 個一小時頻段,但一旦計算出半小時和四分之一小時區域,實際上會使用大約 38 個不同的 UTC 偏移量,跨越 UTC -12:00 到 UTC+14:00。 26 小時的間隔就是為什麼地球上的兩個地方可以在同一時刻位於不同的日曆日期。 IANA 資料庫本身定義了數百個命名區域,因為它追蹤歷史規則和當前規則。
夏令時間隙的時間會發生什麼事?
當時鐘向前彈出時,當地時間的一個小時永遠不會存在,因此紐約過渡之夜的 02:30 並不是真正的讀數。轉換器會在過渡後立即將此類輸入解析到瞬間,而不是默默地傳回錯誤的答案。秋季重疊的時間,即同一掛鐘發生兩次,解析為第一次出現 - 大多數日曆軟體遵循的約定。
