アンカテ

■ コンピュータシステムのサマータイム対応を巡る二つの楽観論

いきなり来年から日本でサマータイムを導入するという話が出てきて、私には到底実現できない話としか思えなかったが、自民党の少なくとも一部の方々は本気で考えているようだ。そもそも、私にはメリットがどこにあるのかわからないがそれは置いておいて、コンピュータシステム側の対応が非常に困難であるということを、なるべく一般の方にわかるように説明してみたいと思う。

5chとツィッターを眺めて見ると、同業者の人は私と同じ意見が多数であるように見えるが、一部楽観的に見ている方もいるのに驚いた。何事にもいろいろな見方があるので、賛否両論の意見があって議論していけばいいことではあるが、その楽観論を見ていると、全く違う立場の二種類の楽観論がある。何がなんでも自分の立場が正しいと主張する気はないが、この二種類の楽観論が絶対両立しないことは確かで、ここだけはハッキリしておかなければならないと強く言いたい。

最悪のケースは、エンジニアの意見を聞いた所、楽観論Aの人が30%、楽観論Bの人が30%、悲観論の人が40%となった場合だ。AB足して60%だからと言って強行すると、楽観論Aの考えていた方法では、楽観論Bが成立せず、楽観論Bの人の方法だと楽観論Aの人が悲鳴を上げて、結局、どちらの楽観論も実現不可能で悲観論が正しかったということになる。

だから、最終的な結論はエンジニア同士の議論になるなるのかもしれないが、回りの人も、その議論の構図はきちんと理解しておく必要があると思う。

楽観論A: 既存の国際化機能を前提とした楽観論

最初のタイプの楽観論は「サマータイムを実施している国はいくらでもあって、そういう国では普通にコンピュータを使っているではないか!」というものだ。

これは正しい。この手の機能は、インターナショナライザイション(国際化)と言って、画面上の英語のテキストが、日本人が見た時には日本語になるのと同じグループの共通化機能とされている。今では、OSでもプログラミング言語でも、ほとんどが国際化の機能を標準で持っており、その中には、サマータイムを含むタイムゾーン(時差)の処理がある。

だから、日本でのサマータイム導入も、対応するのはOSだけで、ユーザもアプリケーションも何も変更なしで、そのまま対応できるケースもある。

特に、スマートフォン用のアプリなどは、逆に、OSや開発ツールが提供している国際化の枠組みからはずれる方が難しいので、何もしなくてもそのままでサマータイムに対応できるものも多いかもしれない。

ただ、注意すべき点は、この国際化とは、コンピュータ内部では、UTCで時刻の情報を持っていることを前提としていることだ。そして、データを保存したりやりとりしたりする時には、UTCで行う。国ごとのローカルタイムに変換するのは、画面に表示する直前で、それ以外では、時刻が全部UTCになっているということが暗黙の前提となっている。

たとえば、私が 8/7 の 午前 10:00 に5ちゃんねるにコメントを投稿したとする。国際化対応されているプログラムでは、この投稿に、「01:00 UTC」という時刻をつけて保存する。UTCとは時差の基準になる時刻のことで、日本の時間より9時間前になっている。そして、表示する時に、「01:00 UTC」を日本時間(JST)に変換して、「10:00 JST」という投稿時刻を表示する。

もし、5ちゃんねるが国際化対応していて、イギリスの人がこの投稿を見ると、「2:00 BST」という投稿時刻が見えるはずだ。イギリスは現在サマータイム期間中で、その時の日本との時差は8時間になる。サマータイムが終わればそれは「1:00 GMT」になる。

多くの国で使われるプログラムはほとんどそうなっているし、アメリカは国内に複数のタイムゾーンがあるので、アメリカ人専用のプログラムでもそうなっている。

ところが、日本人だけが使うプログラムはほとんどそうなっていない。5ちゃんねるもそうだろうと思ったら、案の定そうだった。

日本のプログラムでは、普通、10:00 に投稿したら、そのまま「10:00」という情報を保存する。そして、専用ブラウザに対して、「10:00」という情報を送信して、専用ブラウザは、それに何の変更もしないで、「10:00」と表示する。

どちらが自然だと思いますか？

10:00 に投稿された情報を「10:00」で保存するのと、10から9を引いて「1:00」で保存して、表示する時に9を足して、「10:00」で表示するという二度手間をかけるのと、どちらが自然だと思いますか？

この「9を引いて」とか「9を足して」という処理が、サマータイム期間中は「11を引いて」と「11を足して」になる。こういう所は、国際化の機能を使うと自動的にやってくれるのだが、日本人しか使わないものは、そもそも足したり引いたりする処理を入れる必要がなくて、自然に10:00で保存して自然に10:00で表示する。

それは、国際的に見て標準的とは言えないし、今後はそれではダメだろうと私も思うが、日本人が日本国内でプログラムを作ると、5chのようなやり方になるのが自然だ。

それに、仕事で作るプログラムでは、エンジニアが必要と思っていても客が必要と思わなければ、そういう機能を入れることは許されない。

楽観論B: システム時刻変更を前提とした楽観論

そして、5ちゃんねるのようにローカルタイムで処理することを当然と思っている人の中にも楽観的に見る人がいる。そういう人は「システム時刻を変更してしまえばよい」と言うのだ。

そういう人も年に二回ある切り替えの日には、いろいろややこしい問題があることは認識しているようだが、そういう時は数時間コンピュータを止めてシステム時刻を変更して起動すればよい、と考えている。

もし、サマータイムの時にシステム時刻を進めれば、私の(サマータイム以前の日本標準時で言う)10:00 の投稿は、12:00 で記録される。そして、それを見る時はそのまま 12:00 で配信され、12:00 で表示される。

つまり、こういう人は、システム時刻=ローカルタイムという前提を持っているので、サマータイム対応というのは、そのシステム時刻を年二回進めたり遅らせたりすることだと思っている。

私には、随分乱暴なやり方に思えるが、単体で動いているコンピュータで信頼性より運用コスト低減の方が重要なシステムならば、そうすることにも一理あるとは思う。

というか、私も以前は、こういう考え方をしていた。

私は、1980年代から2010年頃まで国内のメーカー系SIでエンジニアとして仕事をしてきた。その後、フリーランスになって、国際化の必要な仕事をした。その仕事では、仕様書が英語で書かれていて、最新のWEB技術を使った仕事だったが、技術と英語には困らなかった。しかし、国際化機能の使い方がわからなくて、すごく苦労をした。

だから、今では「そうすることにも一理あるとは思う」とか偉そうに言っているが、ついこの間まで「システム時刻=ローカルタイム」と普通に考えていて、それが一番自然だと思っていた。

1990年頃には、証券に関連するシステムの通信制御システムの開発をしていて、このプロジェクトは「一分落ちたら一億円賠償」とか言われるシステムで品質にはすごく厳しくて、WEB系には技術面でその時のプロジェクトリーダーより上の人はいない、と今でも思っているが、そういう難しいシステムでも確か電文上の時刻はローカルタイムだった。

だから、システム時刻を2時間進めたり遅らせたりと考える人がいて、ローカルタイムで通信しようと考える人がいることも間違いないと思う。

二つの楽観論が出会う時

たとえば、あなたが5ちゃんねるの専用ブラウザの作者だとして、「あなたのアプリではサマータイム導入の時どういう影響がありますか？」と聞かれたら、どう考えるだろうか。

専用ブラウザは、ローカルタイムで送られてきた時刻をローカルタイムのまま表示するだけだから、「こちらで対応することは何もない」と思うかもしれない。つまり、あなたは楽観論Bをもとに「たいしたことない、関係ない」と言う。

しかし、5ちゃんねるのサーバ側は、「サマータイムを導入する以上、これを機会に5ちゃんねるもちゃんと国際化しよう」などと考えて、「来年からUTCで時刻を送ります。専用ブラウザの人は、それをローカルタイムに変換して表示してね」と言うかもしれない。これは「OS標準の国際化機能を使えば、処理は簡単でしょ」という楽観論Aの人だ。

確かに追加する処理は簡単かもしれないが、「何もない」と思ってた所に予定外の作業を入れるのは大変だ。

こういう行き違いがたくさん起こると私は考える。

5ちゃんねるであれば、力関係がハッキリしているからまだいい。

もし、専用ブラウザ側の方が権力を持っていたら、さらに話がややこしくなる。

つまり、「こちらが作業するのが大変だから、サーバ側でサマータイムに対応しろ」と言い出す。従来の日本標準時で10:00に投稿されたものを、「10:00」や「12:00」にして送ってこい、ということだ。

おそらく、ローカルタイムで通信しているシステムでは、こういう問題が必ず起きる。技術的な正論は簡単で通信電文上の時刻はUTCであるべきだ。しかし、それによって作業量が増えてしまうケースもあって、通信のあっち側が負担するかこっち側が負担するかという話だと、これは技術者だけでは決められない。ビジネス的、あるいは政治的な力関係の問題になってしまう。

そういう技術と政治のからんだ綱引きを、納期が絶対に動かせないタイトなスケジュールの中でやることになる。

まとめ

私の懸念することをまとめると「通信電文上の時刻の扱いをどうするか合意が取れないケースには、サマータイム導入への対応方法は簡単には決まらない」ということだ。

つまり、掲示板に10:00に投稿された書き込みをサーバはどう配信すべきか

• 常に 1:00 UTC
• サマータイム内には、3:00 、それ以外は 1:00
• 常に 10:00 JST
• サマータイム内には 12:00 JDT、それ以外は 10:00 JST

という選択肢があって、現状すでに 1:00 UTC で統一されているケース以外では、揉めることが避けられないだろうということだ。

「3:00」というのはどういう意味かと言うと、「うちのシステムは、NTPで時刻同期をしてるから、おおもとのタイムサーバの時刻を二時間進めれば問題ない」という意見を見たからだ。

つまり、「NTPが配信している時刻はローカルタイムの事情に動かされることがない固定のUTCである」という前提を理解せずにシステム時刻を変更しようとしているわけで、こういう人は、UTCで通信していてもそのUTCを動かすことを考えるかもしれないと思ったからだ。

そして、この結論によって通信のこっち側とあっち側で対応の工数が変わってくるので、これは簡単に決まらない。

それと、データベース内にローカルタイムが保存されているケースにも、似たような問題が発生して、この場合は、その時刻項目を参照する箇所を洗い出すのが大変だと思う。

そもそも

私は、こういう時に技術者の話が通ることは、日本ではあまりないと思っているのですが、それについては、こちらを参照してください。

• 検非違使の末裔がブログを書き始める日
• 今こそ読もう!「中空構造日本の深層」

Permalink | コメント(0) | トラックバック(0)