このところ、サマータイム導入論が再燃している。場合によっては2019年夏から実施されるという可能性もある。だが、それに対してIT業界や専門家から、「そのような短い期間ではITインフラや情報システムの対応が到底間に合わない」「実施すると、IT関連で広範囲に大きな問題が起こりかねない」という意見が出ている。
2018年9月2日、サマータイム導入に関して科学技術の立場から問題を提起する「サマータイム導入におけるITインフラへの影響に関するシンポジウム」（情報法制研究所、JILIS主催）が開催された。立命館大学情報理工学部の上原哲太郎教授と、国際大学GLOCOMの楠正憲氏が講演を行ったあと、モデレーター/パネリスト5人によるパネルディスカッションが行われた。
以下では、その中から「なぜシステム対応が2019年や2020年には間に合わないと考えられるか」に関連する部分を中心に紹介する。
ITインフラの更新には4～5年が必要
上原教授は、スライド共有サービス「SlideShare」に「2020年にあわせたサマータイム実施は不可能である（Ver.0.1）」というスライドを8月10日にアップし、かなりの反響を呼んだ。
上原教授の主な主張は次の通り。
・ITインフラの更新には4～5年の準備期間が必要
・ソフトウェアの更新には大規模なものなら3年の準備期間が必要
・家電などでは修理や買い換えが必要なものがあるので、国民の負担が増える
・経済損失はインフラで3000億円、全体で1兆円を超える規模になるだろう
・イノベーションにあてるべき人材をサマータイム対応でつぶしてはいけない
ITにおける問題をもう少し細かく分解すると下図のようになる。
（＊ 配信先のサイトでこの記事をお読みの方はこちらで本記事の図表をご覧いただけます。
http://jbpress.ismedia.jp/articles/-/54002）
今回の最大のポイントは、「時計の自動設定」を行う機器の種類と数が以前より格段に増えていることだ。サマータイムによってこれらにどのように影響が出るかを調べ、それに対応するのは容易なことではない。
まず、IT機器やシステムが扱う時刻について整理しておこう。世界全体で使われるのが協定世界時（UTC、Coordinated Universal Time）である。以前はグリニッジ標準時（GMT）と呼ばれていたものだ。そのほか日本では日本標準時（JST、Japan Standard Time）が使われている。UTCをJSTに変換するには9時間を足す。
これまではそれだけでよかったが、もし2時間を前倒しするサマータイムが導入された場合は、UTCに11時間を足して「夏時間」とする必要がある。以下ではUTCに加える時間のことを「時差」と呼ぶ。サマータイムには時差の値を変えることで対応できる。
機器が現在時刻を取得する元（時刻供給源）は何種類もあり、取得できる時刻が異なる。複数のベンダーが参画したシステムでは、どこでどの時刻供給源を使っているかを探し出すという作業が面倒になる。
システムに時刻を与える主な供給源としては、以下のものがある。
NTPサーバーは、NTP（Network Time Protocol）というプロトコルを使って、ネットワークにつながっているコンピュータの時刻をあわせる機能を持つ。
Windows、LinuxなどのコンピュータOSは通常NTPサーバーを時刻供給源としている。OSは内部に「タイムゾーン（TZ）情報」を保持していて、設定されたタイムゾーンにあわせてUTCに時差を加える。タイムゾーン情報は世界各国のサマータイム制度の変更などで更新されるので、日本でサマータイムが導入されても同様の対応になる。ただし、OSを定期的に更新していないシステムではタイムゾーン情報が古いままである。
家電や組み込みOSではJSTで時刻を扱っている場合もある。サマータイムに対応するためには対応が必要だが、ネット経由で更新することはほとんどできないので、機器の修理または交換が必要になる。
多くのネット家電はNTPサーバー経由でUTCを取得しているという。ただ、それに単純に9時間を足しているようだ。この修正は根本部分なのでオンライン更新はできないという。
電波時計はJJYの対応次第
JJYは、JSTを知らせるために情報通信研究機構が送信している電波で、「電波時計」と呼ばれるものは、この信号を受信して時刻合わせを行っている。ところが夏時間になった場合にJJYが夏時間、JSTのどちらの時刻を送信するかは決まっていない。JJYには「夏時間かどうか」を示す情報が加えられているが、何時間ずらすかの情報は含まれていない。
電波時計が夏時間を表示する場合、JJYで夏時間が送信されるならその時刻そのものを表示すればいいが、JSTが送信されるなら夏時間に変更する処理を行う必要がある。電波時計だけでなく、JJYを基に時刻を提供するシステムにも影響が出る。
アプリがそのように組まれているか？
前述のように、パソコンやスマホの主なOSはサマータイムに対応できる仕組みがすでに用意されている。ただ、その上で動くアプリケーションが同様の仕組みを備えているかどうかは別の問題だ。
アプリケーションが「タイムゾーン情報から得られる時差をUTCに加える」方法で時刻を取得していれば、サマータイムへの対応は容易だ。しかし、コンピュータシステムが作られるようになって以来、日本ではサマータイムが導入されていないので、設計者やプログラマがそれを考慮する習慣があまりできていないとみられる。
具体的には、「UTCに9時間を加える」という決め打ちで日本時間を計算していることが多いと思われる。そのように作られたプログラムでも、これまでのように日本時間が固定された世界ではまったく問題なく動作してきたのだ。だがサマータイム対応のためには修正が必要だし、そのためのテストも行わなければならない。
「サマータイムで障害を起こすシステムは、本来やるべき国際化対応をやっていないと言える」とGLOCOMの楠氏は指摘する。「UTCやタイムゾーン情報などを使い、国際標準に沿って設計・開発していれば、問題は起こらないはず。OSや標準ライブラリなどは夏時間の変更にも対応している」。
ただし同時に「現実にいますぐにサマータイムに対応できるかというと心もとない」とも述べた。「システム開発の仕様書にサマータイムの記述があるものはおそらくほとんどないので、開発元に責任を負わせることは難しい。テストをやり直す必要があるが、テストが自動化されていないことが多いので、人海戦術で検証するしかない」。
データの保存や送受信でもこんな課題が
時刻の情報が意味を持つデータの保存や送受信についても注意が必要だ。
USBメモリーのフォーマットとしてはFAT32やexFATなどがあるが、この両者はファイル保存時のタイムスタンプとしてそれぞれJSTとUTCを使う。これらを認識して正しく処理しないとUSBメモリーでファイルの受け渡しをしたときにタイムスタンプがずれてしまう。
「この手の問題はいっぱい起きるだろう。技術的に細かいので、本当によく知っている人しか問題に気づけない」と上原教授は難しさを指摘する。
国内数千カ所に設置されている地震計は、主にGPSからUTCを取得している。一方気象庁に送るデータはJSTなので、単純に9時間足しているものがある。オンラインでのソフトウェア更新はできないので、設置場所におもむいて交換する必要がある。設置者の多数を占める地方自治体はその費用を予算化しておかなければならない。このような課題があるため、送信データをJSTのままにしておく選択肢もあるだろう。ただし、サマータイム対応していて夏時間を送信する機器があれば、今度はそちらを修正しなければならない。
食品流通業界である新日本スーパーマーケット協会と日本加工食品卸協会（日食協）は、サマータイムの実施を取りやめるよう求めた。その理由の一つは、EDI（電子データ交換、Electronic Data Interchange）だ。食品仲卸は、メーカー数千社、小売り数百社との間でEDIを使って注文データをやり取りする。ところが各社で時刻の扱いがバラバラで、統一することが難しい。
もちろん、システムへの影響は、どのような運用を行うかでも大きく異なる。ただし、それを議論して運用方法を決めるだけでも時間がかかる。仮にルールをきちんと作ったとしても、解釈の誤りや実装漏れを完全に防ぐことはできず、いろいろなところに問題が起こる可能性はある。
今回のサマータイム問題を契機に、「時差を考慮した、世界で通用するプログラミング作法が一般的になれば、このような問題が小さくなっていくはずだ、というコンセンサスを得る機会と捉えるのは悪くないのでは」と上原教授は言う。
楠氏は「サマータイム対応にどれだけ時間や手間がかかるかがわからない大きな理由は、仕事がやっつけになっているためだ。書いたコードのドキュメントを残し、社会的な変化に耐えうるような柔軟な設計をする。このような流れを作ることができればいいと思う」と締めくくった。
[もっと知りたい！続けてお読みください →] ボランティアに頼る東京五輪は危なすぎる！
[関連記事]
コメント