關於時區(二)

這篇將延續關於時區(一)的分享。來針對在遇到需要做跨時區判斷時,web前端及後端之間資料傳遞的部份來進行介紹。

在生活周遭中,我們會使用到時區的情況。可能像是:購買跨時區的機票、飯店、物流處理…等。

假設伺服器位於台灣地區(UTC+8),而購買的人是位在澳洲(UTC+10)。那該如何從web前端及後端的角度來處理時區的差異?

我們可以考慮的情況分為:

  • Client端要傳什麼資料給server端,才能讓server端知道client端位於什麼時區?
  • Server端接收到client端的需求(request)後,server端要透過DB的什麼資料型態來回傳時間給client端?
情況1:Client端要傳什麼資料給server端,才能讓server端知道client端位於什麼時區?

在進行思考前要先知道,處於client端的瀏覽器,可以辨識出使用者的時間及地區。所以在這種情況下,我們要思考要傳遞什麼資料才能讓server端知道這是來自哪邊的需求?

通常,我們可能會優先想到client只要傳LT(Local Time)給server端的做法。但如果採用的是這種方式,在資料送達server端後,server端還需要做額外計算的動作。

如:透過LT減掉timestamp(UTC+0)的時間去得知client端是位於哪個時區。

若是換個角度來想,如果僅傳送地區或是直接傳送UTC+多少的數值給server端,那麼當server端一接收到資料後,就能立刻得知client端是位於哪個時區。相較於client端傳送LT的時間給server端的做法,其實還要來的更簡便。

情況2:Server端接收到client端的需求(request)後,server端要透過DB的什麼資料型態來回傳時間給client端?

會提及DB是因為我們可能會透過它來紀錄每次交易發生時的交易時間。

這個接續上篇文章所提到,DB可以用來存取時間的資料型態為:

  • TIMESTAMP
  • DATETIME
  • VARCHAR
  • DATE

在這之中我們先撇除DATE,因為它只能顯示到年、月、日。如果是紀錄交易時間,我們必須得知時、分、秒的數值。

那麼我們該選擇什麼樣DB資料型態來回傳時間呢?

答案是都可以,因為不管選擇什麼樣的資料型態,只要能紀錄到秒,就都可以。這是因為server端在回傳資料給client端時,它們之間的資料傳遞都會是String的字串型態。所以只要能夠回應正確的時間資料給client端就可以。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.