DBにデータを保存するときによくあるcreatedAtやupdatedAtなんかを例に考えるとわかりやすいと思われる。
これらのデータを保存するときには基本的にはUTCで保存しておくと良い(UNIX Timestampだったらそもそも自然とそうなるが)。
タイムゾーンはアプリケーション側で変換なり必要な処理をする。
Railsなどは勝手にそうしている模様。
- 何よりもサマータイムというやっかいなシステム。これがあると実際に時系列などがおかしくなる現象や実際はどの時間なのかわからなくなる事態が発生してしまう。
- 日本のようにサマータイムがないような環境では非常に意識しづらい。
- クライアントのタイムゾーンが違うようなときに基準となるUTCから表示用のタイムゾーンに変換するという共通の処理でコードを書ける。
- これも単一のタイムゾーンしかない日本のような環境でしかサービスをリリースしない状況では意識しづらい。
- アメリカなどの複数のタイムゾーンを持つような国だと国内展開だけのサービスでもこれらは考慮すると思う。
「とりあえず日本でしか展開しない」=>「流行ってきたから海外展開しよう！」みたいなことがビジネスでは起こりうる。 でもDBにはJSTで時刻を保存してしまっている。こんな状況がくるととてもやっかいである。 というか自分はまさにこの状況になっていた。
- データベースには時刻関連のデータはすべてJSTで保存されている。
- なんならサーバーのタイムゾーン設定も
Asia/Tokyoになっている。
お行儀よくやるのであれば、当然データのマイグレーションとアプリケーション側のコードの変更をする。 アプリケーション側のコードはタイムゾーンを考慮して(どのようなデザインパターンを採用するかはさておき)処理を分岐するコードを書けば システムを止めずにリリースすることは理論的にはできるはずである。 データのマイグレーションは必ずメンテナンス時間を設ける必要がありそうに思う。 というか自分はシステムを止めずにマイグレーションする方法を思いついていない。
想像に難くないと思うが、これらの作業は非常に膨大な時間を要する。 データのマイグレーションもそうだが、アプリケーションのコード変更も容易ではない。 なんせテストの数も確実に倍増していくことになる。
ベンチャー企業で上記のような作業をしろと言われても現実的ではない。 なんならタイムゾーン対応を終えるころには会社がつぶれているかもしれない。 海外展開をする時点でタイムゾーン以外にも多言語対応や通貨周りの対応など、 対応しなければならないことは盛りだくさんである。
我々は日本を信じた。何かというとサマータイムは今後しばらく導入されないだろうという勝手な推測の元、 JSTを基準にしてタイムゾーンの関連の計算をすることにした。 UTCの代わりにJSTをアプリケーションの標準と割り切った判断をした。 ちょうど東京五輪2020でサマータイムを導入するかしないかの議論があって、結局導入されなかったというのも判断材料であった。 これによって作業の工数はすごく減ったと思う。 それでもアプリケーション側のコード変更はそこそこ大変だった。
しかも結果としてコロナという状況もあり、結局海外展開は中断することになった。 いろいろ考えると結局この判断は正解だったと思う。 自身は多言語対応や通貨対応、タイムゾーン対応などの貴重な経験を得ることができたのは幸運だった。