只放拖鞋的鞋櫃(已移至 julianchu.net)

前陣子處理了一些 timezone 的問題，現在順手紀錄下來，不然我這顆容量只有幾十 mb 的大腦很快就會忘光了。疏誤之處還請鄉親不吝指導

結論

簡單來說，除非是夠新的瀏覽器，否則 無法 純粹用計算 timezone offset 的方式，在 javascript 裡面正確處理時區的問題，除非你透過 moment-timezone.js 這些已經正確處理完 timezone 的 3rd party library。原因在於 timezone offset 會隨著日光節約時間變換

名詞解釋

雖然大家可能都知道了，還是寫一點名詞解釋，看起來似乎比較認真

UTC

世界協調時間/世界標準時間，英文「Coordinated Universal Time」／法文「Temps Universel Cordonné」，也許跟民族自尊這種無法退讓的問題有關，因此折衷簡寫為 UTC。

這是透過原子鐘計算出來的時間，全世界看到的都應該一樣。再藉由 Z (Zulu) 來做調整，好比 ±hh:mm 的 hh:mm 就是 Zulu

Local time

如果 UTC 的時間是 02:03，對於設定 UTC+8 的人來說， local time 是 10:03；對於設定 UTC+9 的人來說， local time 是 11:03

Local offset

各地區透過 Zulu 來得到這個 offset，目的是希望該區的正午十二點恰好是日當正午。

(其實我個人還滿討厭這件事情，既然「12:00 等於中午」是人工教育出來的，幹嘛還把全世界的時間搞得那麼複雜。反正我們能不能星際旅行還不知道，在不考慮相對論的前提下，全球用同一個時間有多好)(阿宅的抱怨)

Daylight Saving Time

問題的元兇，日光節約時間，又稱夏時制。尤其在高緯度地區，夏天的日出時間跟冬天有不少落差，為了鼓勵大家多當晨型人吸收多點紫外線，用非常人工的方式強制在某幾個月內撥快時鐘。

(其實我很想要收集七顆龍珠，向神龍許願回到過去把提出這個概念的人毒打一頓)
(直接許願日光節約時間消失不是更好？)
(好像乾脆許願 IE 全部消失最好)

問題

其實問題可以用很簡單的例子來演示，因為我是臺灣人，假設我人在台北，打開瀏覽器裡面的時區就是 Asia/Taipei +08:00

• 請問你看文章的當下，日本時間是什麼？
• 請問你看文章的當下，紐約時間是什麼？
• 請問你的時間是 2014/04/01 13:00:00，當時日本的時間是什麼？
• 請問你的時間是 2014/12/01 13:00:00，當時日本的時間是什麼？
• 請問你的時間是 2014/04/01 13:00:00，當時紐約的時間是什麼？
• 請問你的時間是 2014/12/01 13:00:00，當時紐約的時間是什麼？

因為 browse 裡面的 Date 物件處理的都是 local time，所以你產生 Date 物件再吐出 String 的時候都會看見 +08:00。而且這些問題都沒有辦法透過簡單的查表計算，好比說「喔！日本是 UTC+9，所以我把電腦裡面的時間再加 3600 秒就可以了嘛」

因為那張表是浮動而非固定的。原因就是討厭的日光節約時間

對臺灣人來說日光節約時間可能很陌生而得到，「這種鬼東西可以不用鳥它啦」的結論，我一開始也是這麼想。可是一查才知道，美國紐約在 2014/03/09 就有實施日光節約時間，持續到 2014/11/2。

2014 年耶！紐約耶！

如果是火奴魯魯或是南極洲這種你可能一輩子都遇不上來自那裡的客戶地方就算了，如果連紐約最近的時間都無法正確處理可說不過去。

理解日光節約時間的行為，可以看這個 Time changes for USA

在實施日光節約時間以前，現在時間是紐約的凌晨 01:59:58
五秒過後，現在時間變成了 03:00:03，中間有一個小時不見了！

用 Linux 的宅友，可以用指令 tzselect 找出某地區的 timezone 字串，然後塞入變數 TZ 來執行 chrome

$ TZ='America/New_York' chrome

這樣就能偽裝成你去美國紐約玩，沒錢出國的時候不失為一個望梅止渴的旅行法。此時從 console 測試可以看見這些結果

new Date(Date.UTC(2014, 2, 9, 06, 01, 0, 0)).toString()
"Sun Mar 09 2014 01:01:00 GMT-0500 (EST)"

new Date(Date.UTC(2014, 2, 9, 06, 59, 0, 0)).toString()
"Sun Mar 09 2014 01:59:00 GMT-0500 (EST)"

new Date(Date.UTC(2014, 2, 9, 07, 00, 0, 0)).toString()
"Sun Mar 09 2014 03:00:00 GMT-0400 (EDT)"
直接跳到三點了！，無法顯示 02:00:00 ~02:59:59

同一年在 11/02 的時候紐約結束實施日光節約時間，因此那一天會有同一時間出現兩次的奇景

new Date(Date.UTC(2014, 10, 2, 04, 1, 0, 0)).toString()
"Sun Nov 02 2014 00:01:00 GMT-0400 (EDT)"

new Date(Date.UTC(2014, 10, 2, 05, 1, 0, 0)).toString()
"Sun Nov 02 2014 01:01:00 GMT-0400 (EDT)"

new Date(Date.UTC(2014, 10, 2, 06, 1, 0, 0)).toString()
"Sun Nov 02 2014 01:01:00 GMT-0500 (EST)"

雖說 01:01 會出現兩次，細看便知一個在 EDT(Estern Daylight Time) 一個在 EST (Estern Standard Time)。一個在 -0400 一個在 -0500

這就是問題所在。要把某一筆時間顯示為某區的 local time 時，你如果不知道該地區當時是否有實施日光節約時間，所以你不會知道 offset 該是多少，也因此無法計算。

而日光節約時間，比我一開始想像還要常見得多，因此無法假裝不存在而不處理。台灣也有實施過日光節約時間，鴨七有相當詳細的台灣日光節約時間之考據

解法

後來 Date object 有一個 method Date.toLocaleString，可以指定 timezone。不過捲到相容性那邊，看見要 IE11 才開始支援，希望我兒子開始學寫程式的時候已經可以放心使用這個 method

最簡單的就是拿 moment.js 來用，加上 moment-timezone.js 之後就擁有處理時區的能力。即便如此，還是要下載一大包的 data，內含各地區的日光節約時間資料，這三者加在一起才能正常運作。當然也不用每個地區都抓，你的產品有支援的地區包進去就好了。即便如此我還是隨隨便便就超過 100K 了 (淚)

寫這篇其實只是小小的提醒，希望想去貓咪咖啡(Cat Cafe) てまりのおうち(手鞠之家) 的朋友不會跟我一樣犯傻

這次旅遊(2014/07/23)去東京以前，朋友丟了這篇 【日本東京】貓奴必看！森林般的吉祥寺貓咪咖啡-てまりのおうち(手鞠之家) 的連結過來，雖然我不是貓奴，因為家裡有隻很像狗的變態 虎斑貓，恰好我也要去吉祥寺那邊，就順道把這間店排進行程。

按照 Google Map 的指示走到那邊，看見咖啡店無限期休息的告示，心中吶喊一聲「這種店怎麼可能會收！」只好摸摸鼻子離開，直到前天我才發現我走錯地方。

首先，看看 Cat Cafe 的官方網站，寫明地址是 東京都武藏野市吉祥寺本町 2-13-14 3F


從 Google Map 來看相當近，事實上也真的很近，過兩個街口就到了。憑著人體導航的經驗，抓準方向直衝過去看見了門口貼上這張


雖然我只會日文五十音，但是看漢字也猜得出來

• 這是咖啡店的公告
• 這間咖啡店休業中，還不知道什麼時候會再開

但我直到前兩天才發現「唔....名字好像不太對」(出發前沒時間規劃行程，全部丟給老婆弄，所以我都沒認真看店名 XD)

原來.........


我走到了紅色箭頭的地方(以為那邊是路口)，歇業那間叫做エコー咖啡店，但是貓咪咖啡店的入口在綠色箭頭進去三樓，就在旁邊而已....

就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已就在旁邊而已

好吧，反正就是我犯傻了，希望其他朋友不會跟我一樣笨 XD