日本でサマータイム制を絶対に導入してはいけない技術的な理由の一部

何度か浮かび上がっては消えてきたサマータイム制という議論がまた出てきたようですので、（いろいろと忙しいのですが黙ってはいられず）書くことにしました。とにかく実務的に不可能ですから。本当に。

情報システムにおいては、「所定の順番通り、所定の時刻に起動しなければならない仕事」がいろいろとあります。一般のユーザーとしてパソコンを事務作業に使っているだけだとこの種の仕事のイメージが湧きませんが、たとえば銀行振込の処理などがその例です。

「午後３時以後の振込依頼は翌日扱いになる」とかよくありますよね？　ああいう処理は午後３時以後の振込をまとめて翌日の所定時刻に処理してるわけです。

サマータイム制に移行するためには、この種の処理もサマータイム制に正常対応可能なことを検証し、ダメな場合は修正しテストして・・・という手順を踏まなければなりません。

議論の前提として、現在の日本標準時では計時系に関して３つの原則があります。
原則１：UTC表記とJST表記は1対１に対応する
原則２：1日（日付切り替えの間隔）は24時間固定である（うるう秒を除く）
原則３：時刻表記は単調増加する
というものです。UTCというのは「協定世界時」と言われる、コンピュータシステムの時間設定をする際の基準となる時刻体系です。（注：図中の「うるう秒を除いて」という記載は間違いで、UTCとJSTはうるう秒でも1対1に対応します。この原則が崩れるのは UTCと Unixtime との間でした）

現在の日本国内の情報システムはこの原則が崩れたときに特別な対応を迫られる（修正せざるを得ない）ものが非常に多いのです。きわめて面倒くさい話ですがそのうちのごく一部を紹介しましょう。

JST-1～JST-6は日本標準時で表記された時刻を意味すると考えてください。要するにみなさんが日常的に日本国内の時計で目にする時刻のことです。UTC-1～UTC-6はそれに対応するUTC表記です。例えば以下の２つの表記は同一の時刻を指しています。

2018年８月１１日　21:42　JST
2018年８月１１日　12:42　UTC

さて、あるサーバ上でJST-2にSという処理（ジョブ）を起動するように設定していたとします（下図の「コンピュータ処理」のラインを参照）。ここで使用している時刻表記はJST表記であって、UTC表記ではありません。

問題は、この「JST-2」という時刻を決定する際の基準が何種類もあることです。

たとえば、「JST-1に発生するAイベントの後○○分がJST-2だからJST-2にしよう」と、「基準イベント後、所定時間経過」で決定する場合があります。これを(1)イベント後トリガー基準と呼びましょう。

同様に、「JST-3」に発生するBイベントの前○○分がJST-2だからJST-2にしよう」と、「基準イベントまで所定時間となったとき」で決定する場合があります。これを(2)イベント前トリガー基準と呼びましょう。

(3)JST-2イベント発生トリガーというのは、「JST-2という時刻表記が発生した場合に処理する」というものです。たとえば「午前2時には２回、３時なら３回アラームを鳴らす」といった、時刻表記に依存する処理がありえます（まあ、非常に少ないと思いますが）。

(4)UTCイベント発生トリガーというのは、JSTに関係なくUTC基準で決定すべきトリガーです。これも希少な例ではありますが「太陽の南中時刻に処理を始める」といった、物理現象に合わせて設定する処理ではあり得ます。

問題は、「JST-2にSジョブを起動する」という設定情報だけではそのJST-2がどの基準で設定されたものかがわからず、サマータイム時の対応も決められない、ということです。

仮に下図のようにJST-2を含む前後1時間（2時間でもいいですが）がサマータイム移行時に「飛ばされる」時間だとしましょう。

その場合、JST-2は存在せず、UTC-2はJST-3と表記されるようになります。このとき、「JST-2に起動する」と設定していたSジョブはどう扱えばよいのでしょうか？

もしSジョブが(1)イベント後トリガーのジョブであれば、正しく処理させるためには起動時刻をJST-3に変更しなければなりません。

もしSジョブが(2)イベント前トリガーのジョブであれば、正しく処理させるためには起動時刻を「JST-3 よりも所定の時間前」に変更しなければなりません。

もしSジョブが(3) JST-2イベント発生トリガー のジョブだった場合、そもそもJST-2は発生しないので実行不要です（というより、Sを起動してはいけない）

もしSジョブが (4) UTCイベント発生トリガー のジョブだった場合、UTC-2に合わせて起動するためにはJST-3に変えなければいけません。

ざっと考えただけでこの4種類存在し、それぞれ扱いが違うわけです。実際には(1)イベント後トリガーでも先行イベントのタイミングにも依存しますし、扱いはこれ以上に複雑になります。

大規模な情報システムではこのような「所定の順番通り、所定の時刻に起動しなければならないジョブ」がネットワークのように連鎖しています。それらの起動タイミングを決定する基準にはサマータイムの影響を受けるもの（営業時間に応じて決まるものはその例）もあれば、受けないもの（UTC基準で決まるものや海外企業との取引など）もあります。

その基準の違いはジョブ実行の設定データだけを見てもわかりません。
たとえば、UNIX/Linux系システムに標準搭載されている簡易ジョブスケジューリングシステムであるcronの設定データはこんな形式です。

# 毎日午前2時30分に ajob.sh を実行する
30 2 * * * ajob.sh

単に起動する時刻を書いてあるだけです。サマータイムになったときにこれをどうしたらよいかを判断する手がかりはありません。したがって、変換スクリプト等をかまして自動的に対応するのは不可能です。

一般のPCユーザーの目には見えませんが現代の情報システムではそこら中にこの種の「JST表記の時間に依存する設定」があります。それをすべて精査し検証し修正しテストするのでしょうか。あまりにも非現実的です。

高度なジョブ管理システムでは複数のジョブ間の依存関係を定義して制御できますが、それらにしても冒頭に挙げた3つの原則を前提として実装されているものなので、サマータイム制下で正常に動作するのかどうかは慎重に検証しなければいけません。

要するに、大規模なシステムトラブルなしにサマータイム制へ移行するのは不可能だということです。

（あー、でもこの場合の「大規模なシステムトラブル」というのもイメージ伝わってないんだろうな・・・ワタシゃこれを東日本大震災が3つ4つ来るぐらいのイメージで考えてるんですがね・・・）