Global Service でのタイムゾーンの設計

タイムゾーン問題

「タイムゾーンはマルチスレッドプログラミングのようにそれ自体が難しさを抱えている」という前提に立つ必要があると私は考えています。
　　-- グローバルサービスでのタイムゾーンとの向き合い方
　　https://quipper.hatenablog.com/entry/2016/12/05/090000

前提となる状況

Globalにスケジューリングや実行ログを伴うようなサービスを構築しています。
ユーザーのLocaleと同じくタイムゾーンに応じて時間を表示し、スケジュール実行を予約します。
サーバサイドでは、まとめて処理を行うため、１つのデータベース上に複数のタイムゾーンによって設定・生成された時間が存在します。

結論

1. 保存される時間のタイムゾーンを UTC に統一する
2. サーバサイド（Rails）で扱うタイムゾーンをUTCに統一する
3. DBのカラムはDateTime型で保存する
4. フロントエンドとサーバサイド間はUnix Timestampに統一する
5. フロントエンドでは、利用者の設定に応じてタイムゾーンを変換表示する
6. 日時入力は利用者の設定に応じたタイムゾーンで行う

フロントエンドには Rails View と、Vuejs によるSFCがあります。

どのような問題が生じうるか

複数タイムゾーンを考慮しない場合、次の間で時間がずれる危険性を持ってしまいます。

1. DBとアプリケーション
2. サーバサイドとフロントエンド
3. 運用に伴う、過去の記録時間と今後生じるの時間
4. 利用者によるタイムゾーン変更
5. 外部連携システムの時間

ずれる原因

現在時間そのものが、２つの要因で変動するためです。
1. 現在という、それ自体が変化する値である
2. 時差という利用者の属性によって変化する値である

変化を固定化するには

変化する値は、基準を設けることで起点が定まり計算可能になります。
タイムゾーンは、基準をUTCにしています。
現在時間を止めることはできませんが、Unixタイムスタンプは起点時間を設けています。
そのため、アプリケーションもこうした基準値に寄せることが適切だと判断しました。