はじめに
フロントエンドからパラメータとして受け取るタイムゾーンがバックエンド側、DBとどのような関係であるのかを理解し、思い出せるために、備忘録としてこの記事を作成する。
この記事は、著者がクライアントからあるデータを更新するEndpointの作成のための仕様書を作成するにあたって、疑問に思ったことを記している。
結論
仕様書のリクエストパラメータのsampletime
このタイムゾーンは、UTCと表記するべきである。(プロジェクトや仕様によって異なる)
前提
DB(PostgreSQL)でのタイムゾーンはUTCである。
ここでは、あるdatime型のパラメータをsampletimeとする。(実際の中身はコンプライアンスに反するので省略)
課題
フロントエンドから送られてくるリクエストパラメータの中身のsampletime
このパラメータのタイムゾーンは、何が基準なのかが明確でなかった。(UTCなのかJST,GMT)
これらを明確にしないと以下のような誤った処理の例が生まれてしまう。
誤った日時処理の例
① フロントエンドからの入力
ユーザーが日時を入力: 2024-12-11 00:00:00
フロントエンドでは、これを JST（日本標準時） として意図して送信。
② データベースに保存
サーバー側で特にタイムゾーン変換をせず、そのままデータベースに保存。
データベースではUTCとして保存される前提のため、この値は 2024-12-11 00:00:00 (UTC) として解釈される。
③ データを利用する
ユーザーに日時を表示するとき、DBに保存されている 2024-12-11 00:00:00 (UTC) をJSTに変換。
UTC→JSTの変換で+9時間され、結果的に 2024-12-11 09:00:00 (JST) として表示される。
④ 結果
本来ユーザーが意図した2024-12-11 00:00:00 (JST) ではなく、誤った日時（2024-12-11 09:00:00 JST） が表示される。
解決策
自身が開発しているプロダクトでは、ユーザーから受け取った値をフロントエンドでUTCに統一しているケースが大半であるので、リクエストパラメータのsampletime
このタイムゾーンは、UTCで送られてくる。
そのため、仕様書のパラメータのvalueのタイムゾーンはUTCとするべきである。
参考文献
https://buildersbox.corp-sansan.com/entry/2022/02/01/110000
https://qiita.com/kazuho39/items/58986109a705c82380d6