ブリティッシュコロンビア州のタイムゾーンとPostgreSQL：日付処理の落とし穴を回避する

ブリティッシュコロンビア州のような地域でのタイムゾーン管理は、PostgreSQLを利用するエンジニアにとって非常に頭の痛い問題です。夏時間の切り替わりや地域特有のオフセット設定により、日付データに予期せぬズレが生じることがあります。PostgreSQLでタイムゾーンを安全に取り扱うためには、timestamptz型を適切に活用し、アプリケーション層ではなくDB層で正しくUTC変換を行う戦略が不可欠です。本稿では、複雑なタイムゾーンの仕組みを理解し、正確なデータ設計を行うためのベストプラクティスを解説します。

素晴らしい投稿だね！この件について少し考えていたんだけど、データベースレベルで解決するための自分なりのアプローチがこれだよ：https://github.com/acalvino4/pg_temporal (https://github.com/acalvino4/pg_temporal) リリースの公開方法やドキュメントの整理方法が決まったらShowHNに投稿しようと思ってる。今のバージョンでも基本的なユースケースなら動くはずだから、レポジトリをクローンしてコマンドを実行する手間を厭わないなら試してみてよ！

データベースにはUTCのUnixタイムスタンプ以外は保存すべきじゃないと思うな。どうしても別の方法で時間を保存しなきゃいけないなら投稿にある2カラム手法でもいいけど、その変換はソフトウェアライブラリ側に任せるべきだよ。時間の変換処理はすべてソフトウェアに任せて、実績のあるライブラリを使って、決して手動で計算しちゃダメ。タイムゾーンはあまりにも危険が多すぎて、自前で実装なんてできないよ。（追記：言いたいことを分かりやすくするために表現を少し変更したよ）

この戦略だと時計の針が戻る時間の予約には対応できないよ。その時間は曖昧で、2つの異なる時点を指す可能性があるからね。その点を除けば、悪くないよ。

未来のイベントについては、現地（イベント開催地）の日時とタイムゾーンを保存しておくといい。そうすれば、もし法律が変わっても正しいコンテキストを維持できる。2026年9月14日月曜の朝8時30分に医者を予約したいなら、それが夏時間であろうが標準時間であろうが、あるいは予約時と受診時の間に「誰か」が端数時間を変更しようが関係ないからね。過去のイベントについてはUTCタイムスタンプを使おう。形式はどうすべきかって？長期保存用には人間が読める文字列がいいよ。何かがおかしくなった時のデバッグが簡単だからね。注意点として、クエリを最適化するために整数（Unixタイムスタンプなど）のオフセットを保存するフィールドを追加したり、計算インデックスを使ったりするのは構わないけど、どれがマスターデータなのかは常に明確にしておくこと。

ANSI SQLにはDATE型とTIME型があるんだから、場所に関連する予約にはそれを使えばいい。現在のユーザーのタイムゾーンへの変換はプレゼンテーション層で行うべきで、データベースが関与すべきことじゃないよ。

もう一つややこしいのは、ブリティッシュコロンビア州の一部が別のタイムゾーンを使っていることだね。南東部はアルバータ時間（以前はMST/MDTだったけどMDTに移行中）に従っているし、北東の一部や確かCrestonのようなコミュニティは歴史的にMST（サマータイムなし）に従っていて、今ではバンクーバーと同じ時間帯になっている（タイムゾーンの呼び名は違うかもしれないけど）。

ブリティッシュコロンビア州の愚かな変更だよ。ソースは俺、BC州民より。

この問題は目新しいものじゃないし、TZ変換で日常的に扱う問題からすれば比較的些細なことだよ。世界中のいろんな場所でサマータイムを採用するかどうかの日付が違うし、過去にその日付を変更した国だってある。ライブラリを使いな。自作しちゃダメだし、tzdataを出し抜こうなんて思わないで。もし自分ならできると思うなら、プロジェクトに貢献して新しいChronomancer[1]になるか、その思い込みを捨ててくるといいよ。1. これは法的な称号で、実際にtzdataに貢献した人はChronomancerと呼ばなきゃいけないんだ。法律で決まってるからね。

時刻はローカルなもの。タイムスタンプはカウンターだ。Unixタイムスタンプにタイムゾーンの違いなんて存在しない。ただのカウンターだよ。世界のどこにいようが、タイムスタンプは同じ瞬間に同じ数値を返すはずだ。タイムゾーンで調整されるようなものじゃない。その数値を、未調整のまま信頼できる情報源として保存すること。そこからなら、どんなローカルタイムにだって変換できるから。

tz関連の投稿を見るたびに言いたくなるんだけど、みんな知ってるかな。tzdataパッケージが使っているデータは、UCLAのすごい教授、Paul Eggertが管理しているeggert/tzのものだよ。一度彼のコースを受けたことがあるんだけど、試験に自分でも答えが分からないような問題を出してくる人だったよ。