タイムゾーンって日本で生まれ育って過ごしていると「JSTを選んどけばいいやつね」くらいの認識で止まってしまってて、あるのはわかっているけどいまいちあやふやだよなぁというのを改めるために少し調べてみました。
というつもりだったんですが、単によもやま話を集めただけになってしまったような……。全編を通してですが、自分がアバウトに知る程度に集めた話なので、正確性には欠けます。
タイムゾーンってなに
時間は最初は太陽の動きを基準に決まっていたけれど、これだと経度が違うと時間も違ってしまう。場所ごとに使用する時間が違うと不便になるので、ある程度社会的につながりの近い地域では同じ時間を使うようになった。この同じ時間を使うエリアがタイムゾーン。
だいたい国単位でタイムゾーンが決まるけれど、東西に長い国では国内に複数のタイムゾーンがある場合もある。経度が近ければ一つのタイムゾーンに複数の国が属することもある。
UTCってなに
タイムゾーンの基準になる時間。
原子時計に基づく国際原子時(TAI)と、地球の自転に基づく世界時(UT)という二つの時間がある。原子時計は正確に時を刻むけれど、地球の自転は不規則。日常生活では太陽の動きに合わせる UT の方が便利だけど、観測によって決定される UT では未来の時間が正確に表せないなど不便さがある。ということで TAI にうるう秒を入れて UT との差を1秒以内にした UTC が策定された。TAI は秒数が連続してるけど UTC は秒数が連続してないことに注意が必要。
GMTってどこいった
世界標準時と言えば、かつては GMT(グリニッジ標準時/Greenwich Mean Time) だった。これはイギリスのグリニッジ天文台を通るグリニッジ子午線を基準とした太陽時。実際には1972年に UTC を世界基準時にすることになったが、1990年代でも GMT と呼んでた気がする。昔の名残だったのかもしれない。
グリニッジ標準時が世界標準時に決まったと共にグリニッジ子午線が経度0度に定まったわけだが、日付変更線=経度180度がちょうど太平洋上にきて陸地で日付変更線をまたがなくて不便が少ないという理由もあったと思う。
日付変更線
UTC を中心に+12時から-12時までのタイムゾーンがあるわけだが、理屈の上では+13時でも+14時でも+100時でもいくらでも伸ばしていくことができる。これじゃ無茶苦茶になってしまうので、日付変更線を超えた際には日付の方を1日プラスもしくはマイナスすることなった。結果、日本からハワイに行ったら前日に着いてしまったりする。
タイムゾーンが違えば隣町でも時間が変わるのは仕方ないけれど、日付変更線を超えたら日付まで変わってしまうのでは大変1。だから日付変更線は陸地が少ない太平洋上が選ばれているわけだけど、だからって影響を受ける地域が全くないわけでもない。仕方なく実際の日付変更線は結構曲がってしまっている。
うるう秒
TAI と UT との差を UTC 上で吸収するために挿入または削除される秒。
挿入される場合は8時59分59秒のあとに8時59分60秒がやってきて9時0分0秒となる。削除の場合は8時59分58秒の次が9時0分0秒になる。
コンピュータシステムではうるう秒を考慮していなくて誤作動を起こすこともある。そのため正確性は少し犠牲になるが、前後数時間の1秒を微妙に調整して見かけ上時間を連続させる運用もある。
tz database
世界中の全てのタイムゾーンをボランティアの手によって収集されたデータベースが tz database。ボランティアといいつつ、多くのコンピュータシステムに採用されていて、事実上の標準になっている。
現在のタイムゾーンだけではなく、過去のタイムゾーンの変遷の歴史も全て記録されている。
South Ryukyu Islands
tz database は人の手で編集されるため、時には間違いが混入することもある。日本にまつわるところでは、Asia/Tokyo 以外に Asia/Ishigaki(South Ryukyu Islands / UTC+8)が登録されていた。阿呆な私は当時 FreeBSD をインストールするときに実際にこれを見て「へえ、日本にも時差はあるんだ」とか勝手に納得していたが、実は参照した文献のミスであったことが判明し2、現在は修正されている。
サマータイム
夏の日照時間を有効に使うために、夏の間だけ標準時をずらす施策。
同じタイムゾーンでも国によってサマータイムを実施したりしなかったりするので、結果的にさらにタイムゾーンが増えている。
日本のサマータイム
現代日本人としてはサマータイムは外国の話と感じるが、日本でも1948年から1952年に実施されたことがある。この時代の日時を扱うシステムでは日本国内専用であってもサマータイムを考慮しなければならない。
サマータイムによって起こるトラブル
タイムゾーンだけでも十分にやっかいだが、サマータイムが絡んでくるとさらにやっかいになる。コンピュータシステムに限っていっても、
- ログの日時が逆転する
- 日次バッチが1日2回実行される/実行されない
などの問題が起こる可能性がある。cron はサマータイムに対応しているために実際には2回実行やバッチ飛ばしは起こらないが、時間をずらして実行する予定のバッチが同時に動いてしまうなどの事態は起こりえる。
両方が兄の双子
ログの逆転が現実世界で起きた例として、両方が兄の双子が生まれたことがある。
まず一人目が産まれた後にサマータイムが終了して時間が戻り、二人目が産まれたと。産まれた順番と時刻が逆転してしまったわけである。社会によっては後に産まれたほうを兄とする場合もあるので、その例を適用すれば混乱はないのかもしれない。
いろんなタイムゾーン
キリバス
かつて国内に日付変更線があったが、現在は解消している。結果として UTC+14 をもつことになったため、世界で一番早く日が変わる国の一つになった。
サモア、トケラウ
地理的に近い大国であるオーストラリアとの時差を小さくするため、日付変更線を超えたタイムゾーンの変更があった。
チャタム諸島、西オーストラリア州、ネパール
ほとんどのタイムゾーンでの標準時は0分もしくは30分だが、これらの地域では45分の標準時を採用している。
コンピュータシステムにおけるタイムゾーンの扱い
理想的には全ての日時データは UTC で保存し、入出力時には現地のタイムゾーンに都度変換するのが正しいだろう。
とはいえ、日本国内でしか使わないとか、ごく短期間で使い捨てられることが決まっているようなシステムでは日本のローカルタイムゾーンでシステムを組んでもいいとは思う。ただ、システムが当初の予定を超えて成長し国をまたいで使用される可能性がゼロではない。そうなったときに改めてタイムゾーンに対応する修正は非常に大変になることは想像される。