サマータイムの話題のついでにUNIX時間、UTCあたりの復習をする
サマータイムが話題ですが、流行に乗っかってサマータイムはプログラム上どのように表現されるか、考えてみたい。
UNIX時間、UTC、JST
議論の出発点としてプログラムで時間がどのように扱われるか、一般的なところから初めて見る。
まず、コンピュータ上の表現として、UNIX時間(unixtime, posix time)というものがある。
これは時刻を数値表現として扱うよう、1970年1月1日0:00:00を起点に、そこから何秒経過したか形式的に計算したものとなる。
試しにrubyで実行してみると、
irb(main):003:0> t = Time.now => 2018-08-12 01:40:47 +0900 irb(main):004:0> t.to_i => 1534005647
となった。1年は606024*365で約3153万秒なので、約48.65年経過していることになった。 これはだいたい正しそうだ。
しかし1970年からの経過秒数だけがわかっても今が何日かは正確にはわからない。なぜなら暦は定期的にメンテナンスされるからだ。
そこで協定世界時(UTC Coordinated Universal Time)という概念がある。これは厳密な仕組みは物理学的な話なので飛ばすとして、要するに国際的な機関が正確な暦のためにうるう秒を挿入したりと暦をアップデートすることで、季節がだんだんずれたりすることがないようにしている。
この記事を書くにあたり調べて初めて知ったが、UTC→UNIX時間は一意だが、UNIX時間からUTCは一意とは限らない(うるう秒の挿入・削除をUNIX時間は考慮しないから。したがって1970年からの経過秒数というのは厳密には誤り)
で、そうこうして国際的な機関が決めたUTCに、9時間を足したのがJST(Japan Standard Time)となる。例えば今は日本時間で深夜1:59だが、表記としては+0900をつけてUTCから9時間進んでいることを示している。
irb(main):003:0> Time.current => 2018-08-12 01:59:35 +0900
ちなみにイギリスはグリニッジ天文台が云々という話を地理で習ったと思うが、UTC+0を標準時にしている。ただし夏季はUTC+1となる。
したがって、今日本で提案されているサマータイムとは、夏季限定でJSTをUTC+9から、UTC+10とかUTC+11にするということだ。
どういうところで問題になりそうか
ユーザーが時間を選択する or サマータイムの有無をまたいで使用するケースがある
例えば7月頭でサマータイムの運用が開始するとして、ユーザーが6月30日15:00スタートのチケットと7月1日15:00スタートのチケットを購入するとする。これは内部的にはサマータイムがUTC+10だとして、2018-06-30 15:00:00 +0900, 2018-07-01 15:00:00 +1000 になる。 まぁこれだけなら意外とすんなり扱えそうだけど、サービスによっては24時間以内に重複した申込みがあったらNGというバリデーションを設置しているかもしれない。するとこれはサマータイム適用時に1時間早く進んでいるから、間が23時間しか空いていない。これは多くのアプリケーションではセーフにしたそうだけど、ものによってはNGかもしれない。
だいいち、ユーザーがサマータイムを想定してその時間を選んでいるかどうかも厳密には怪しい(これはUIで頑張るしかないけど)。
バッチ処理
OSのtimezoneがJSTであれば、cronの挙動は8:00にデイリーで動かすバッチ処理があったとしたら、サマータイムの前も後も8:00で動くはずだ(たぶん)。 しかしUTCで動いているとサマータイムの前と後で名目上、動く時間が変わる(たぶん)。
またバッチ処理には24時間分のデータがある前提で動くものもあり得る。私が開発した経験があるものでもわりと不安なものがいくつかある。
*** そもそも検証する工数が確実に発生する
JSTの定義が変わるとおそらく言語・ライブラリのアップデートが必要になる。逆に言えばアプリケーションレベルではほとんど手を入れずに動くものも多いかもしれない。しかしながら確実に動作確認なり問題がないことの検証なりの工数は発生するわけで、多くのケースではこれで人手不足になるのではないか。(そしてサマータイム運用コンサルなる謎のSIが生まれるかもしれない)
そのへんのベンチャーのサービスならともかく、勘定系などでとてつもないQAが発生するのは間違いない。
で、賛成か反対か
壮絶な反対多数のネット世論の中こういう事を言うのはリスクだが、私はサマータイム賛成派だ。ゴールドマン・サックスの友人が海外で働いていたとき、定時で仕事が終わったときにまだ明るかったのに飲みに行った経験が非常に良かったという。私もそれを日本で体験してみたい。
エンジニアとしては2点ある。1点目は、そもそもサマータイム自体がそこまで突飛な話ではないから、エンジニアとして想定すべきというか、拒否するような話ではないと思うからだ。例えば消費税を8%に増税するとき、増税はシステム上想定してないから絶対反対だといってるようなものだ。
2点目は、別に社会はエンジニアが何をやりたいかから決まるわけではない。社会的な課題や利便性があるなら、そのためにシステムやプロダクトを作って課題を解決する、社会の利便性をあげる。これがエンジニアの心的姿勢だと思う。一応サマータイム導入の海外の事例や経済効果の試算は存在する。批判するならそれを覆すだけのコストとリスクがあるという話を定量的にするしかない。
