台灣是 UTC+8;憑記憶算時差為什麼會錯
台灣使用「中原標準時間」(CST,UTC+8),與中國大陸、香港、澳門、新加坡、馬來西亞、菲律賓相同,全年不採日光節約時間。
換算本身只是加減,會出事的是「那一天到底差幾小時」。偏移不是一個地方的固定屬性,而是一個地方在某個時刻的屬性:歐美多數國家一年調兩次時鐘,各國調的日子還不一樣。台北跟紐約冬天差 13 小時、夏天差 12 小時。所以這頁要你連日期一起選,每張城市卡都用該日期當下生效的偏移去算。
該加哪些城市
- 一個人一張卡,不是一個國家一張卡:美國、加拿大、澳洲、巴西、墨西哥、印尼、俄羅斯境內都不只一個時區,「美國團隊」不是一個時間。
- 跨三個時區以上就加 UTC:它永遠不動,是唯一一個寫進文件半年後還成立的時間。
- 看到縮寫就改查城市:CST 可以是芝加哥、上海或哈瓦那,PT、CET 也一樣要先問清楚對方人在哪個城市。
- 長得一樣其實不一樣的地方:鳳凰城全年不調時、丹佛會調,夏令期間兩地差一小時;澳洲的布里斯本與雪梨是同一個陷阱。
- 不是整點的時區:印度 UTC+5:30、尼泊爾 UTC+5:45,伊朗、阿富汗、緬甸也是同一類,別當成整點加減。
- 找一個不會動的定錨:台北、東京、新加坡、香港、檀香山全年不調時,其他城市都在變的時候特別好用。
如何使用本工具
預設顯示你裝置目前時間在 5 個城市的對應時刻,可以再從 90 個城市裡挑要加的。如需查詢特定時間(例如「下週三早上 10 點台北時間,紐約是幾點」),在頂部欄位指定日期與時間,所有城市會即時更新。
- 用「新增城市」把你要的城市加進來,搜尋框吃中文名、英文名與 IANA 代碼(例如 Asia/Tokyo);用不到的卡片按右上角的叉叉移除。
- 指定日期與時間,日期要填真正要用的那一天,不要用今天代打。這一步就是在防你不知道的那次調時。
- 讀卡片時連日期一起讀。台北的星期三早上可能是紐約的星期二晚上,只抄時間不抄日期是最常見的誤會。
- 想回到當下,按「使用目前時間」,畫面會回到每秒更新的即時模式。
- 要傳給別人時按城市卡下方的「複製這幾個城市的時間」,清單上每個城市一行,城市名、日期、星期、時刻與 UTC 偏移都帶上,例如「台北 2026/12/08(二)21:00 UTC+8」。
實戰教學:排一場台北、紐約、倫敦都醒著的會
- 避開所有人深夜:晚上 22:00 ~ 早上 07:00 通常不該排正式會議
- 找重疊時段:例如台北跟紐約,台北早上 8 ~ 10 點是紐約前一天晚上 7 ~ 9 點(夏令期間是 8 ~ 10 點),雙方都還醒著
三地一起開的話,可用的帶很窄。台北早上 8 點,紐約是前一天晚上 7 或 8 點,但倫敦是午夜到凌晨 1 點;挪到台北下午 4 點,倫敦是上午,紐約卻是凌晨 3 或 4 點。三地都落在 07:00 到 22:00 之間的只有台北晚上:台北 21:00 開一小時,冬天是倫敦 13:00、紐約 08:00,夏令期間是倫敦 14:00、紐約 09:00。往前挪到台北 20:00,冬天的紐約是早上 7 點,剛好踩線;往後挪到 22:00,換台北踩線。
排好之後,邀請函上每一個時間都要黏著城市名,日期也要寫出來:「2026/12/8(二)21:00 台北 / 13:00 倫敦 / 08:00 紐約」這種寫法,比只寫一個時間再讓大家自己換算安全得多;跨日的組合(例如台北早上對紐約前一天晚上)要各寫各的日期。固定每週開的會,在 3 月、4 月、10 月、11 月各檢查一次,那是各國調時的月份。
把換算好的時間傳給別人
- 寫明時區:寄出會議邀請時,信件主旨直接寫「Mon 10 AM TPE / Sun 9 PM EST」(夏令期間是 Sun 10 PM EDT),減少誤解
- 用 ISO 8601 格式:書面記錄時用
2026-06-22T10:00+08:00這種帶時區偏移的標記,沒有歧義 - 複製時連城市名一起複製:聊天室裡出現一個沒有城市的時間,對方只能用猜的。工具的「複製這幾個城市的時間」就是照這個寫法組的,每一行都黏著城市名與日期。
- 放進日曆邀請最保險:Google 日曆、Outlook、Apple 行事曆都是把活動連同時區一起存,國外的與會者打開就看到自己的當地時間。建立時先確認活動用的是你們談好的那個時區。
各地時差對照與日光節約時間
台灣與亞洲常用時區對照
台灣常往來的亞洲、大洋洲地區時區,與台灣時間的時差速查。澳洲部分州與紐西蘭在當地夏季(約 10 月到隔年 4 月)採 DST,那段期間時差會多 1 小時。
| 地區 | 時區 | 與台灣時差 |
|---|---|---|
| 台灣 / 中國 / 香港 / 新加坡 / 馬來西亞 / 菲律賓 | UTC+8 | ±0 |
| 日本 / 韓國 | UTC+9 | +1 hr |
| 越南 / 泰國 / 印尼(雅加達) | UTC+7 | −1 hr |
| 緬甸 | UTC+6:30 | −1.5 hr |
| 印度 / 斯里蘭卡 | UTC+5:30 | −2.5 hr |
| 尼泊爾 | UTC+5:45 | −2.25 hr |
| 杜拜 / 阿布達比 | UTC+4 | −4 hr |
| 澳洲(雪梨 / 墨爾本) | UTC+10 / +11 DST | +2 / +3 hr |
| 澳洲(伯斯) | UTC+8 | ±0 |
| 紐西蘭(奧克蘭) | UTC+12 / +13 DST | +4 / +5 hr |
日光節約時間(DST)
日光節約時間(Daylight Saving Time)是為了「夏天天亮得早,把時鐘撥快 1 小時讓人們提早起,節省照明電力」設計的制度。各國採用狀況差異很大:
- 採用 DST:美國(3 月第 2 週日 ~ 11 月第 1 週日)、加拿大、歐盟(3 月最後週日 ~ 10 月最後週日)、英國、澳洲部分州、紐西蘭
- 不採 DST:台灣、中國、香港、日本、韓國、新加坡、印度、俄羅斯、巴西、夏威夷、亞利桑那州、澳洲昆士蘭州
DST 切換導致台北與紐約的時差從冬季 13 小時,夏季變 12 小時,跟倫敦則從 8 小時變 7 小時。工具會依你選的日期套用各城市當天的 DST 狀態,不必手動切換。
使用提醒
裝置的時鐘與時區是一切的起點。設錯的話每張卡都會錯同樣多,而且 VPN 改不了它。本地那張卡看起來怪怪的,先去檢查作業系統的日期與時區設定。
一年有兩個小時不聽話。時鐘往前撥的那天,當地有一個小時整個不存在;往後撥的那天,有一個小時發生兩次。會議排在這兩段裡本來就是有歧義的,換一個時間比事後爭論省事。
規則會變,有時候還很臨時。近年有國家取消、恢復或移動過自己的夏令時間規定,美國與歐盟也都討論過乾脆廢掉換季調時。本頁寫的是通例,排半年以上的行程前先確認當年度的規定,處理規則變更前的舊日期也要多留意。
時區資料是跟著系統更新來的。IANA 的時區資料庫一年會改好幾次,透過作業系統更新送到你的裝置上。長期沒更新的手機、電腦或伺服器,遇到剛改過規定的國家就可能差一小時。
常見問題
台灣是 UTC 幾?
台灣的標準時間(CST)為 UTC+8,全年不採用日光節約時間,與中國大陸、香港、新加坡相同。
為什麼夏天從台灣打到美國紐約變 12 小時時差?
美國紐約位於東部時區(EST,UTC-5),但在 3 月至 11 月間採用日光節約時間(EDT,UTC-4),因此時差從冬季的 13 小時縮短為夏季的 12 小時。
為什麼程式碼裡時間都該存 UTC?
資料庫儲存用 UTC,前端顯示時再用 Intl.DateTimeFormat 依使用者裝置時區轉換。這樣 server 不必猜使用者在哪,跨地區排序也不會出錯;夏令時間往回撥的那一小時,當地時間會重複出現一次,存 UTC 才分得出哪一筆在前。
UTC 跟 GMT 一樣嗎?
日常使用幾乎可互換,但學術上 UTC 是用原子鐘定義(更精準),GMT 是以英國格林威治皇家天文台太陽位置定義。UTC 偶爾會插入閏秒(leap second)來對齊地球自轉的微小誤差。
為什麼有些時區不是整點?
時區由各國自己訂,不一定是整點。印度 UTC+5:30、伊朗 UTC+3:30、阿富汗 UTC+4:30、緬甸 UTC+6:30、尼泊爾 UTC+5:45,換算時不能當成整點加減。
資料來源
- IANA Time Zone Database:城市代碼與各國調時規則的源頭,你的裝置用的也是它。
- MDN Intl.DateTimeFormat:本頁用來把一個時刻格式化成某個具名時區當地時間的瀏覽器 API。
- 美國的夏令時間起訖(3 月第 2 個週日到 11 月第 1 個週日):15 U.S.C. § 260a。
- 歐盟的夏令時間起訖(3 月最後一個週日到 10 月最後一個週日,依 Directive 2000/84/EC)與廢除換季調時提案的進度:European Commission:Summertime。
- 英國的調時日(2026 年是 3 月 29 日與 10 月 25 日):GOV.UK:When do the clocks change?。
更多時間工具
要倒數某個時刻(跨年、發售、截止),用「倒數計時器」;程式裡拿到一串 Unix 秒數想看成人類時間,用「時間戳轉換」;要算兩個日期之間扣掉週末剩幾天,看「工作天計算機」;跨國報價順便要換匯,用「匯率換算」。
相關工具
隱私:所有換算都用你裝置上已經有的時區資料在瀏覽器裡完成,你查的時間不會送到任何地方;你自己加的城市清單只存在這台瀏覽器的本機儲存空間。
