少しでも世界で使われる可能性があるならDBのタイムゾーンはUTCにしよう！

こんにちは、エンジニアの @sukechannnn です！

私たちは2022年7月25日にノンデスクワーカー向けプロジェクト管理アプリKANNAの英語版をリリースしました。私は現在グローバル推進チームのリーダーを努めており、日本で提供することしか想定されていなかったシステムを国際化する対応を行っています。プロジェクトスタートから約半年で英語版をリリースしました。

その中でもタイムゾーンの対応はとても大変で、最初からこうだったら…と思わずにはいられませんでした。僕らの反省が、これから世界展開するサービスを開発されるエンジニアの参考になれば嬉しいです。

結論: 少しでも世界で使われる可能性があるならDBのタイムゾーンはUTCにしよう

結論は以上です。理由は、DBのタイムゾーンを JST → UTC に変換するのは死ぬほど大変だから。

それでも、どうしても初速を出すためにJSTで開発したい場合は、PostgresQL を使うことをオススメします。理由は以下の通り。

• PostgresQL は timestamp 型が使えるため（バージョン8.4以降は2038年問題がない）
  • MySQL の timestamp 型には2038年問題があるので利用がためらわれる
• 日時（datetime）に関するデータを timestamp 型で保存しておけば、DBの設定を JST → UTC にするだけで保存してあるデータのタイムゾーンも自動で変更される

私たちの場合

以下のような構成を採用していました。

• DB: MySQL
• タイムゾーン設定: JST
• 主要な日時のデータ型: datetime

海外展開するに当たってDBのタイムゾーン設定をUTCにすることは必須なのですが、datetime 型のデータはタイムゾーンを考慮しません。DBのタイムゾーン設定を JST → UTC に変更しても 2023-10-10 12:00:00 のデータは 2023-10-10 12:00:00 のままです。

そのため、既に保存してある datetime 型のデータを全て-9時間して、2023-10-10 12:00:00 であれば 2023-10-10 03:00:00 になるように変換する処理が必要になります。

datetime 型のデータには created_at, updated_at も含まれるため、結果的に全てのレコードを更新しなければなりませんでした。本番環境のDBのデータを全て更新する…システムによっては不可能な場合もあるかもしれません。

私たちはこの更新作業を、深夜にメンテナンス時間を取って行いました。事前に開発環境で何度もシミュレーションして臨んだのですが、メンテナンス当日に想定外の事態が発生しロールバックしてやり直すことになったりと、とても大変でした。最終的に成功してリリースできたので良かったのですが、最初からUTCだったら…とﾁｮｯﾄは思いました(笑)

まとめ

少しでも世界で使われる可能性があるならDBのタイムゾーンはUTCにしましょう！