2018年08月24日

サマータイム (その1)

サマータイム導入の議論がにわかに盛り上がっています。きっかけはあと2年に迫った東京オリンピック。確かに普通に生活するだけでもバテバテなのに、この暑さの中で限界まで運動することには危険性すら感じます。

全体的な反応としては、やはり反対論が多いようですね。もっとも多くは時間をある時1時間進める/戻すなんてやったこともないし大変そうという、変わることに対する抵抗感のようにも見えます。一方で、IT業界からは切実な反対論が出ています。サマータイムへの切り替え時に時間を1時間進めることで、存在しない時間ができ、また、サマータイム終了時に1時間戻すことで同じ時間が生まれてしまいます。前者はまだ何とかなりますが、問題は後者です。時刻はトランザクションの前後関係の管理に使われますが、サマータイム終了直前の取引と、サマータイム終了直後(時間が1時間戻った後)の取引を単純に時刻で比較すれば、順番が逆転しかねないからです。これはシステムの根幹に関わる大問題です。

とはいえ、海外ではサマータイムは一般的に行われている訳で、もちろんシステム上の解決法は存在します。それは、絶対的な軸を採用すること。時刻で言えば、UTC(協定世界時)を採用することです。もともと米国の場合は一つの国の中で時差があり、LAの午後5時は、NYの午後7時より遅い、つまりローカルタイムを時刻の比較には使えません。ですから、システムの内部的にはUTCという絶対的な時間で管理するようになっています。つまりLAの午後5時(サマータイム)はUTCで翌日の午前0時、NY(サマータイム)の午後7時はUTCで午後11時、ですからUTC同士で比較すれば、LAの午後5時はNYの午後7時より遅いと正しく順番を判定することができます。

ちなみにほとんどのコンピュータの時刻は既にUTCベースになっています。具体的には、内部的にはUTCで管理しており、それを表示する際にローカルタイムに合わせるようになっています(厳密にはUTCそのものではなく、UTCに変換できるシステム時刻で管理しています)。ですから、日本でサマータイムを導入しても、突然PCの動作がおかしくなるということはありません。問題はアプリケーションで、アプリケーションのロジックの中で、ローカルタイムベースでの管理・比較するケースが存在します。

これはある意味元号と西暦の関係に似ています。元号では、昭和30年と平成30年で「30年」が被ってしまいますから、年だけでの前後関係の比較はできません。それが西暦であれば1955年と2018年と前後関係の比較が可能になります。年に関しても、かつては元号で管理しているアプリケーションも存在していましたが、平成になった際に問題が認識され、既に西暦による管理が当然になっています。だからこそ、この先予定される改元は、そこまでの大ごとにはならないのです(以前お話ししたように、出力という観点では改修が必要になりますが、システムの根幹部分にまでは手を入れずに済むようになっています)。

現実問題として、東京オリンピックまでにありとあらゆるアプリケーションをUTCベースの管理にする(既にUTCベースになっているとしても、検証は必要です)というのは不可能でしょう。ですから、残念ながら東京オリンピックに向けてサマータイムを導入するというのは現実的とは思えません。
posted by 岡本浩一郎 at 17:29 | TrackBack(0) | ビジネス
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/184250217
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック