はじめに
あらためて書くが、サマータイム導入には大反対である。システムの問題も大きいが、サマータイム推進派が唱える導入によるメリットも懐疑的である。また1日の周期が変わることによる人間に強いる負荷も大きく、サマータイムにはデメリットしかないのではと考えている。
しかしながらサマータイム導入に反対でも、技術面では興味深く、サマータイム対応に必要なものを考えてみることは悪いことではない。そこでざっくり考えてみたところ、サマータイム導入には次にあげる項目での対応が必要ではないか。
- 時計がサマータイムに対応できるか
- サマータイム移行日に無くなる時間帯が発生するが問題は無いか
- 標準時に戻る日に同じ時間帯が発生するが問題は無いか
- 1日が24時間より短くなることに問題は無いか
- 1日が24時間より長くなることに問題は無いか
- 電文(通信内容)で利用している時刻に問題は無いか
これ以外にも気づいてない問題があるかもしれないので、そのようなものがあればご指摘いただきたい1。
なお以下の説明では、日本標準時をJST、日本夏時間を JDST (Japan Daylight Saving Time)で示す2。日本夏時間については JDST のオフセットを 2時間とし、JST→JDST の切り替えを 6月1日の午前2時JST、JDST→JST の切り替えを 10月1日の午前2時JDSTとする。
1. 時計がサマータイムに対応できるか
いうまでもなく、サマータイム対応に必須の事項である。サマータイムに切り替わっているのに時計が通常の時間のままではお話にならない。
時計をサマータイムに対応させる場合、単純に時刻をずらすだけで対応できるものもあれば、標準時間を別途管理できないと破綻するものもある。というのもサマータイムとして扱う時刻は、ヒトが生活する上で認識する時刻であり、時間の流れとしての時刻に不連続な流れが入ってはならないのである。
ヒトが認識する時刻の代表的なデバイスは一般的な時計であり、JST⇔JDST の切替時点で時刻をずらせば問題は無い。ただし時計の場合、目覚ましのアラームについて注意が必要となることは言うまでもない(笑)。
不連続な時間の流れで困る例として、日本からアメリカ西海岸に飛行機で移動する前後でデジタルカメラで写真を撮ることを考えてみる。日本をある日の午後に出発すると、西海岸に到着するのはたいてい同じ日の午前中となる。それぞれの現地時間にカメラの時計を合わせると、日本で撮影したものが時間の流れとして先であるのに西海岸で撮影した写真データに早い時刻が記録され、時刻順で並び替えると撮影の順番が逆転する。
つまり、システムがサマータイムに対応できるということは、それを使うヒトが認識する時刻(ここでは JDST だが、一般的には「ローカル時間」)と、情報として記録する時刻(標準時、ここでは JST や UTC )を明確に区別して扱えるようになっている必要がある。
UNIX系のシステムは時刻管理にUTCを使い、Time Zone Database (zoneinfo)で時差を管理しすることで、ローカル時間を扱っているため、zoneinfo に正しくサマータイムの情報を加えれば、システムの時間やファイルのタイムスタンプ等には問題が起きない。しかし UNIX系システムで稼働するプログラムであっても、サマータイムを考慮していないアプリケーションでは、ローカル時間と標準時間の区別が明確に扱えていないことによりトラブルが発生するのは容易に想像できる。
日本で使われている組み込み系や制御用の機器は Time Zone Database みたいなものを持っておらず、日本の時間は一種類で普遍の JST であり、ヒトが認識する時刻とシステムの時刻を独立に管理する仕組みを持っていないものが殆どである可能性が高い。そのため、サマータイムに対応できないものが多数あると考えられる。これらのサマータイムへの対応は簡単では無い。
2. サマータイム移行日に無くなる時間帯が発生するが問題は無いか
JST から JDST へ切り替わる2019年6月1日の時刻の変化を並べると次3のようになる。左側が午前2:00にJST から JDST へ切り替わって2時間進む時計、右側が JST の時計である。
$ tzdiff -t 2019-06-01T00:00 JDST
JDST
2019-06-01 00:00 JST 2019-06-01 00:00 JST
2019-06-01 01:00 JST 2019-06-01 01:00 JST
2019-06-01 04:00 JDST 2019-06-01 02:00 JST
2019-06-01 05:00 JDST 2019-06-01 03:00 JST
2019-06-01 06:00 JDST 2019-06-01 04:00 JST
2019-06-01 07:00 JDST 2019-06-01 05:00 JST
2019-06-01 08:00 JDST 2019-06-01 06:00 JST
2019-06-01 09:00 JDST 2019-06-01 07:00 JST
2019-06-01 10:00 JDST 2019-06-01 08:00 JST
2019-06-01 11:00 JDST 2019-06-01 09:00 JST
見てわかる通り、JDST に切り替わった日は、見かけ上 2:00:00 から3:59:59 の時間帯が無くなる。
もし毎日動作するプログラムの起動時間が午前3時に設定されている場合、そのプログラムはサマータイムに切り替わる日には全く起動されないことも考えられる。
3. 標準時に戻る日に同じ時間帯が発生するが問題は無いか
今度は2と逆のパターンで、JDST から JST に戻る場合の話である。9月30日の夜から10月1日の朝にかけてサマータイムが終了し、通常の時間に戻る。
$ tzdiff -t 2019-09-30T20:00 JDST
JDST
2019-09-30 22:00 JDST 2019-09-30 20:00 JST
2019-09-30 23:00 JDST 2019-09-30 21:00 JST
2019-10-01 00:00 JDST 2019-09-30 22:00 JST
2019-10-01 01:00 JDST 2019-09-30 23:00 JST
2019-10-01 00:00 JST 2019-10-01 00:00 JST
2019-10-01 01:00 JST 2019-10-01 01:00 JST
2019-10-01 02:00 JST 2019-10-01 02:00 JST
2019-10-01 03:00 JST 2019-10-01 03:00 JST
2019-10-01 04:00 JST 2019-10-01 04:00 JST
2019-10-01 05:00 JST 2019-10-01 05:00 JST
ご覧の通り JST に戻る際には 0:00 から 1:59:59 の時間帯が JDST の分と JST の分で発生する。
簡単な例として、1時間毎に年月日時分をファイル名に含むログを出力しているプログラムがあった場合、サマータイムを考慮していないと logfile-20191001000.txt という名前のログファイルは、JDST の分を記録した後に JST の同じ時刻によって上書きされ、JDST の分は消失しトラブルとなる。
4. 1日が24時間より短くなることに問題は無いか
JST から JDST に切り替わる当日は、2時間進むことにより 1日の時間が 22時間となる。例えばWebのアクセス数は、(夜中なので影響は少ないかもしれないが) 1日分の集計数が減ることが考えられる。アクセスログ程度では大した問題では無いが、1日が22時間になることで、24時間周期で動いているプログラムは予定より2時間遅れて起動することになる。
もっと短いスパンで考えると、この日は夜の時間が2時間短くなる。毎日 1:00 に開始して、5:00 までに終了しないといけないバッチジョブを例にとると、通常であれば 4時間のジョブタイムが確保できるが、この日は2時間しかないことでジョブタイムが不足し 5:00 までに終了しないトラブルになるかもしれない。
5. 1日が24時間より長くなることに問題は無いか
これは 4の逆のパターンであるが、JDST から JST に戻る日は 1日が 26時間となる。24時間周期を前提にしているプログラムだと、次のプログラムが本来起動するべき時刻より早く起動してトラブルとなるかもしれない。
6. 電文(通信内容)で利用している時刻に問題は無いか
現在のシステムでは、別のシステムと相互に通信を行って稼働しているものが多数あり、通信内容には時刻情報を含まれていることも多い。ここでの時刻の扱いがどうなっているのかに関しては、JDST を導入するに当たって十分注意する必要がある。通信する一方が JST として時刻を扱っているのに、もう一方では JDST として扱えばトラブルになるのは明白である。電文の時刻の扱いは、通信先との調整が必要で、場合よっては国外の組織にまで影響が及ぶかもしれない。特に分散システムでは、どこか一つのシステムでも JDST と JST の解釈を誤れば、その影響は系全体に及ぶ。
おわりに
以上の通り、サマータイムの導入は容易ではない。立命館大学の上原先生の書かれた説明資料には100%賛同する。ましてや2019年からのサマータイムの試験導入なんて話は絵に描いた餅でしかない。