白話文解說如何處理跨時區問題

只要使用者來自世界各地，就一定會遇到跨時區的問題，像是跨境電商的包裹出貨時間、收件時間，或者是電子信箱的收信、發信時間等等，都需要處理跨時區的問題，因為讓使用者自己換算時間的話不僅體驗差，也容易有客服問題產生（譬如預定到貨時間沒顯示正確時區，就可能讓客服多收幾封信）。

後端處理跨時區的最佳實務就是統一存 UTC 時區的時間 。

譬如 JavaScript 的 new Date().getTime() 回傳的就是 UTC 時區的 timestamp ( 1970-01-01 到現在所經過的毫秒數，請記得系統時區也要設定為 UTC) ， 就很適合存到資料庫中。

提醒一下，要存 UTC 時區的 timestamp 的話，最好確定帶入 1970-01-01 的 timestamp 結果是 0, 以 Python 為例，它的結果就不是 0:

>>> from datetime import datetime
>>> datetime(1970, 1, 1).timestamp()
-28800.0

這是因為 Python 預設會使用 local timezone, 所以台灣當地 1970-01-01 的 UTC timestamp 是 -28800, 因為台灣時區快 8 小時，所以 UTC 還在 1969-12-31 呢⋯⋯。

存好 UTC 時區的 timestamp 之後，下一個問題就是如何呈現正確的時間給使用者。

方法有 2 種：

1. 請前端 / App 工程師收到 UTC timestamp 之後自己根據瀏覽器或裝置的時區資訊進行轉換。
2. 在後端對 UTC timestamp 進行轉換，但是需要前端將使用者的時區做為參數傳給後端，後端才能知道如何轉換。

這 2 種方法各有優缺，在前端做轉換的好處是後端可以節省一些運算時間，但是有 3 種平台的話，前端就得做 3 次相同邏輯；在後端作轉換的好處是前端可以省下轉換的功夫，但是後端會犧牲一些回應速度，而且有可能還要處理跨國時間格式問題。

轉換的公式是（實際上有時區參數跟 UTC timestamp 就可以呼叫相關函數轉換，不用自己實作）：

UTC timestamp + time zone offset

time zone offset 是本地時區與 UTC 時區之間的時間差，單位則是看各語言的實作方式而定， JavaScript 是以分鐘為單位，如果你的 UTC timestamp 是毫秒為單位，那麼 time zone offset 就得再轉為毫秒後進行相加。

以台灣為例， 1970-01-01 的 UTC timestamp (毫秒)轉為台灣當地時間的 timestamp 是：

0 + (480 * 60000)

上述的值再除以 3600000 就得到 8, 也就是早上 8 點，不過實際上可以丟給函式庫幫忙轉為人類習慣的日期時間格式。

這邊也要注意每個語言函式庫的 time zone offset 計算方式不太一樣，以 JavaScript 為例是 UTC 時區減去當地時區，所以台灣的 time zone offset 會是 -480, 有些違反我們的直覺，因此 JavaScript 要用減法 UTC timestamp - time zone offset。 (這也是為什麼 MongoDB 的文件是用減法處理 ）

所以使用與 getTimezoneOffset 類似的函數時，最好都要確認一下它的計算方式，才能算出正確的時間。

以上，就是關於時區轉換的魔法啦！