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

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

後端處理跨時區的最佳實務就是統一存 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 類似的函數時,最好都要確認一下它的計算方式,才能算出正確的時間。

以上,就是關於時區轉換的魔法啦!

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

追蹤新知

看完這篇文章了嗎?還意猶未盡的話,追蹤粉絲專頁吧!

我們每天至少分享 1 篇文章/新聞或者實用的軟體/工具,讓你輕鬆增廣見聞提升專業能力!如果你喜歡我們的文章,或是想了解更多特定主題的教學,歡迎到我們的粉絲專頁按讚、留言讓我們知道。你的鼓勵,是我們的原力!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!