タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ

こんにちは、server-side kotlin や terraform を書くことが多い、エンジニアリングGの矢崎(id:Saiya)です。 タイムゾーンや日時の扱いについての話題がホットな昨今ですが、 そういった日時の扱いについて例えば以下のようなお話を受けることが少なからずありました: とりあえず日時は UTC からの時差情報付きで扱えばいいんでしょ？ DB に保存するときもタイムゾーン情報付きで入れておけばいいんでしょ？ こういったお話を振られた際に、思うところを一言でサッと説明できずもやもやする事もあり、 また web サービスにおいて日時・タイムゾーン・オフセットをどう扱うべきか？納得の行く説明をあまり見つけられなかったため、 筆者なりに考えをまとめてみました。 国家的祭典のために急にサマータイムが導入されるといった話に限らず、 クラウドサービスが UTC+0 の日時になってい

[Sampo]

サマータイム移行日の「長い1日」で顧客実損が出た実例→ https://qiita.com/hnw/items/8a422ccbc63dfbd9e3b9

[uunfo]

オフセット指定の+9:00 JSTとタイムゾーン指定のAsia/Tokyoは違う、と。／これはサマータイム関係なく考慮しないといけない内容。ここまでやっていても値の意図がローカルタイムなのかどうかはわからない

[zonu_exe]

たのむ、Accept-Languageヘッダの濫用はやめてくれ、推測の参考にもしない方がいい。 “ユーザーの言語設定をもとに推測する”

[ad2217]

excel などの入力では日付なしの時間のみの入力が結構ある。しかも過去の入力も十分あり得る。そしてJDTなどを付けると方眼エクセルのフォーマットがズレる。

[tagomoris]

人間の活動にあわせたスケジュール実行をどう表現するかが難しいんですよね、毎日朝10時に窓口を開けたい、みたいな。ローカル時刻10時がDST移行で消滅したらどうするか。

[kirarichang]

UNIX epoch を使えばええやんと思っていたが，言われてみると確かに取り回しが厳しい．

[wats2012]

空気読んでくれるモジュールがあったりなかったりするから、DBに書き込んでから読み出すと9時間戻ってて日付も変わってるみたいな事よくある。

[jtw]

素人はすべての仕組みを管理者が理解して構築されており、適時更改されていると思っているようだ。んなわけあるか！！

[monochrome_K2]

普段気にしてなかったけどWebのログなどではオフセット時間が記録されるから一応区別はできるのか。でも考えれば考えるほど連続性を保っていた日本時間を手放すほどのメリットはなく馬鹿げた話だと思う

[hihi01]

素人考えではこれを読むとサマータイム導入で騒いでいる人達は自分の時間処理対応が完璧でないと自白しているだけだと思えてくる。

[nntsugu]

ZonedTimeZone設定を使わわない方がいい説明をするときに読み返す場所。 tz databaseを常に最新にたもっていないとサマータイムでバグを生むかも。OffsetTimeZoneが安全そうね

[nagaitakeyuki]

LocalDateTime, ZonedDateTime, OffsetDateTimeの違い。

[hirorock]

日付の取り扱い 悩ましい問題 サマータイム UTC date

[reannkara]

しっくりきた。

[tak4hir0]

タイムゾーンを考慮した日時の扱いのベストプラクティス

[pmint]

UNIXタイムに時差情報を付け足す？タイムゾーンの話もセキュリティの話と同じく、明快でないほうが有難がられる傾向にあるのでは。日本のIT技術者は意外と苦労するのが好き。やりがいを求めてる。

[digo]

JavascriptでAPI叩く実装が多いのでクライアントからWEBサーバーに送る時点でオフセット付にしちゃう

[tmatsuu]

ZonedDateTimeとOffsetDateTimeの概念の違いはわかるが、この説明での使い分け方が理解できなかった。修行が足りない。海外のサービスだと設定画面でタイムゾーンをユーザに選ばせる実装もあるよね。

[uxlayman]

ほんとこれ。まさにこの通り。ユーザー入力のような推測不可能な場合を除いては、オフセットをもっとけばいいだけの話だし、オフセットを持てるデータ型あるいはISO8601で持ってればよい。ほんとこれ

[bobbyjam99]

“LocalDateTime, ZonedDateTime, OffsetDateTime ”

[mobius118_7]

UNIX時間だと誰かが1900/1/1からの時間を渡してきて時差が凄いことになりそう

[y-kawaz]

あーんーなんか言いたいけど面倒だからいいや。

[lainof]

サマータイムがある国ではベストプラクティスが既にあるんじゃないの？無い(システムごとに考える必要がある)ならそれがサマータイムを導入すべきではない理由の一つになる。

[kagerou_ts]

(ブコメより)騒いでる人たちは ×自分の時間処理対応が完璧でないと自白しているだけ ○関わってるシステムの時間処理対応が完璧でない可能性を自覚してるだけ すでに動いてる、古きシステムの話してるから

[unyaa]

後で試す

[gnety]

MySQLの場合DATETIMEを使った方がいい。UTC+9固定で考えれば何も問題ない

[fa11enprince]

うーん。だいぶ厄介だ(´；Д；｀)

[enemyoffreedom]

ところどころ、あまりベストではない気もするが

[bopperjp]

DBの保存データで結局オフセットが消えるので、内部的にはUTC or Unix Time で扱って、APIの境界面でOffsetDatetimeにするのが良さそう。その場合、日時集計データとかどう扱ってんだろ？tzに依存するし。

[cl-gaku]

タイムゾーンとオフセットってこういうことか。こうして整理されると腑に落ちる

[umaemong]

内部的にはUTCで統一(日時データ形式にオフセットを持てない環境もあるから、『オフセットは常に±0』で統一する)。UIをどうするかは要件次第なので、『○○がベストプラクティス』という考え方はよくないと思う。

[joker1007]

基本、システム内部はUTCが良いと思う。MySQLはオフセットもタイムゾーンも保持できないので、MySQL使うならUTCかUnix timeののどちらかしか選択肢がなくて、表示や丸めが必要な時にTZ引いてきて変換が妥当では。

[toris-birds]

詳しく検討していないけれど、定期的なジョブ実行が絡む案件だと多分Asia/Tokyoは悪手(例えば夏に冬時間で設定したジョブの日時の表示はとか)。あとオフセット情報を使う場合SQLで日付の範囲がらみのものがあると怖そう。

[love0hate]

MySQLだとOffsetDateTimeとしてTIMESTAMPがあるが、これはこれで2038年問題があるし、悩みのタネは尽きない。

[ksugimori]

Googleカレンダーみたいにユーザーに選ばせてオフセット付きで保存した方が安全な気がする。 サーバー側で “空気を読んで解釈” するとクレーム入れるユーザーも出てきそう。

[hylom]

サマータイムが実施されたとき、過去のサマータイム実施以前の該当期間の処理をどうするかについては考えが及んでなかったなあ、面倒だわ