サマータイムは簡単、という記事があまりにあれな件（novtanの日常）

今回はnovtanさんのブログ『novtanの日常』からご寄稿いただきました。

サマータイムは簡単、という記事があまりにあれな件（novtanの日常）

いくらなんでもこれはひどい、という記事があり、はてブでも総スカンを食らっていますが、ちょっと解説。

「サマータイム導入はコンピュータシステム的に難あり」は本当か*1

*1：「サマータイム導入はコンピュータシステム的に難あり」は本当か」2018年08月10日『BLOGOS』
http://blogos.com/article/317015/?p=2

コンピュータ（システムやプログラム）には「時間経過」の概念がありません。命令を受けた瞬間からの経過時間は、秒単位でカウントアップしていくだけで、つまり「その瞬間」しかコンピュータは認識していません。

のっけから何を言いたいのかわかりませんが、「時間経過」の概念はプログラムには当然仕様として必要であればあります。例えば、ジョブ（ここでは、時間になったら起動して、一連の処理を行って終了するプログラム、と考えてください）の遅延時間監視をしていて、起動後３０分経ったらハングアップしている可能性があるのでアラートをあげる、というシステムがあったとして、１２：００にスタートしたジョブが１０分後に時刻が１時間先に進んで１３：１０になったらまだ１０分しか経ってないのにアラートが上がりますね。なので何も考えないと日本中のシステムがアラートだらけになりますね。

もう少し、かみ砕くと、「いま何時？ 3時か、あと2時間仕事しなければ」という発想はなく、命令された時間だけ作業を繰り返しているということです。

これもかみ砕いているわけじゃなくて適当なことを言っているだけですが、そもそもシステムが「発想」することはありませんが、今何時？３時か、後２時間は要求を受け付けなくては、という判断はしますよ。つまり、ATMが１５時になったら振込を翌日扱いにしますよ、という仕様は「いま何時？」をメインの基準にしているわけです。「命令された時間だけ作業を繰り返している」？なんの話？

これをプログラミングにより擬似的に、時間経過の概念があるように見せかけているのが、エアコンなどの「タイマー機能」です。

これも大嘘で、エアコンのタイマー機能は「システムが持っている所定の時刻になったら所定の動作をすることを設定する」わけなので時間経過の概念がそもそも不要ですね。これまで述べてきた例とは全く違う機能です。補足すると、エアコンのタイマーのようにエアコンに閉じたシステムにおいて、サマータイムの影響なんて当たり前ですがありませんよ。例が悪い。しかもインターネット家電的な意味で例えばスマホのアプリから予約をするとかになってスマホがサマータイム、エアコンはサマータイム非対応だと時間ずれますね。

反対に「時間の経過」を確認するプログラミングをすると、秒単位でカウントアップしていく内部時間とは別の、外部時間（時計）を用意しておかなければならず、さらに両者を絶えず確認しなければならないので、二度手間三度手間になってしまいます。

何を言っているのかさっぱりわかりませんが、複雑なシステムじゃなくても、ストップウォッチのことを考えれば時計と時間を測る機能はカウントが別なのは当たり前ですよね。手間の問題じゃなく、実現したい要件の問題です。

だから、どこかの瞬間、サマータイムにより2時間ないし、何時間と時間がずれても、そのまま処理するだけで影響は軽微です。目覚まし時計の時間がずれたら直すように「サマータイム」となったとき、コンピュータの時計を合わせ直せば良いだけのことです。

はいでました、「時間をずらせば良い」。これ言っている人は基本的にシステムのことをわかってない人です。わかりやすい。この人今までタイマーの話ししかしていないし、時計のことをコンピューターシステムのすべてと思っているんでしょうか。そもそもここまでで出てきた二度手間三度手間の話がないと仮定すると、ストップウォッチで時間測っていたらさっきまで１時間経過だったのが１秒後に３時間経過に変わってた、みたいになるってのこの人理解してるの？

ええと、電車一つとっても終電後３時に車庫に入ったのが次に始発向けに４時に出ていくはずが、２時間ずれて２時に出ていかなきゃならない、となったら破綻してますよね。システムの運用でさっき触れたジョブみたいなのも話は一緒なので時計ずらせばOKってのはシステムをパソコンレベルの用途しか考えてないんですよね。

ホストコンピュータなどと接続していて、連続した情報をやりとりしているシステムなら、バチっと電源を落として、その後の立ち上げで日時の変更をすればよいだけのこと。

ええと、そのホストコンピュータはどうすればいいんですかね。そもそもバチッと電源を落とす機会なんて今どき月イチあれば良い方ですよ。で、日時変更したら予定している作業スキップしちゃったりしたらどうするんですかね。簡単に言い過ぎ。

コンピュータに詳しくない人は、人間の意識する「時間」、便宜上「自然時間」と呼ぶとすれば、これを基準にコンピュータのことを考えます。
サマータイムとなり自然時間の定義が変われば、コンピュータも同時に変えなければと「思いこみ」ますが、コンピュータが処理に用いているのは、埋め込まれたクォーツが刻む「内部時間」だけです。

違いまーす。コンピューターが用いているのは、「データ」と「システム時刻」です。データには時刻の関連項目がありますね。みなさんに一番身近なのはファイルの更新時刻とかですね。ブログの更新時間なんてのもデータで持ってますよね。表示されるでしょ。まさかこれをずっと「内部時間で刻んている」わけないよね。X時間前、という更新時刻は当然XX:XX時というデータと今の時刻の比較をしているので、システム時間をバーンと変えたらX時間前との相対関係が変わって表示変わっちゃいますよね。

というのは、サマータイムなどのことを考慮していないシステムが直面する事態で、日本固有のシステムはたいてい直面する事態ですね。

日時の処理は、内部時間を変換して行っているに過ぎず、自然時間の概念をコンピュータは必要としません。

この文章は正しいですね。だからなんだって言うのだ？コンピューターが必要なのはデータとシステムの整合性ってだけ。今までの話はそこを一切無視していますよこの人。

なお、日時の変更はすべてのコンピュータシステムでできます。仮にできないコンピュータがあれば欠陥品と断言できます。なぜなら、内部時間を刻むクォーツには誤差があり、これを絶えず修正しなければなりません。

ほんとこの人時計の話しかしねーな。

最新のシステムではネットを介した日時の自動修正や、電波時計を用いた萬年単位で狂いのないシステムを構築することもできますが、それでも、日付またぎ、年またぎ、うるう日のチェックなどのために、「日付を設定する機能」というのは必ず必要となるからです。

ほんとこの人時計の話しかしねーな。

コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。

ほんとこの人時計（レベル）の話しかしねーな。

なお、西暦の下二桁が0になる年にうるう日はありません。一方、400で割り切れる年はうるう日になります。つまり、2000年2月29日は、400年に1回訪れるうるう日でしたが、その400年に1回に対応するように、私が従事ししていたコンビニのPOSシステムは設計されていました。たしか昭和の終わり頃には。

よく、2000年がうるう年にならない問題は初心者を測る問題とされているのでこの話を嬉々として持ち出す人はそのレベルの話をしていると考えて良いですね。ところで、この話は完全に蛇足ですね。時刻の話をしているのであって日付の話はしていません。ほんとこの人時計の話しかしねーな。

つまり、日時変更できないコンピュータは、これらの処理を確認していない欠陥品だということです。

ほんとこの人時計の話しかしねーな。

サマータイムは日付変更すればすむ話し。一方で24時間、365日絶えず稼働しなければならないコンピュータで、日付を変更するわずかな時間すら許されない場合はどうするか。

先のコンビニのPOSシステムでさえ、サマータイムにはいつでも対応できるように設計されていました。平成元年の時点なので、いまから30年近く前のことです。海外の事例を参考に、変更開始日時と、その変更時間の幅と、終了時刻を処理する仕組みが考えられていたのです。実際に店舗に配備されたレジに、その機能は搭載していませんでしたが、ゴーサインがあれば、瞬時に対応できるようにしていたのです

あのさあ。みんな「そうなってないシステムがたくさんあるのだよ日本には」という話をしているの理解してます？自分が従事していたシステムがたまたま対応してたからってドヤっちゃうの？

プログラミングとは、その時点において考え得るすべてを洗い出し、対応できることは対応し、将来、予想されることに備えておくものです。

はいはいあなたが考えたんじゃないよね。それはさておき、その時点において考えられることがたまたまサマータイムだったというだけでドヤれるってまともなシステム屋さんの感覚じゃないよね。そりゃできることはやったほうが良いけど、そのために必要なコストとか期間とかがお客さんの予算を超えて行われることは、ないです。

余談にそれますが、小学生からのプログラミング教育が無駄だというのは、実戦においてはプログラミング言語よりも、こうした常識と知識を踏まえて、可能性をさぐる論理力が求められるからです。

ここまでの論理展開で説得力が皆無。

話を戻せば、浮かんでは消え、なんども議論されている、サマータイムへの対応、あるいは準備をしていないコンピュータ・システムの業者がいるなら、静かに退場すべきであり、裏返せば、多くのシステム屋はある程度の備えをしているものだということです。

何度も言いますが、サマータイムの対応には当初から備えたとしても金と時間がかかり、それでもなお、クリアできない課題があるわけですね。ある程度の備え、なんて当たり前の話で、複雑な運用をしていないシステムであればいいタイミングでどーんと時刻変更、でもなんとかなると思いますよ。そういうのでは太刀打ちできないシステムの話をしているわけです。時計の話じゃないからね。1日が22時間になったり26時間になったりするときに、俺の利子返せと言ってくる人にどう対応するかなんてことまで考える必要ありますからねー。

なにより、今の時点からでも即座に対応できる程度のことです。2018年8月8日の読売新聞は「元号の変更とあわせてシステム改修が間に合わない」と書いていましたが、あまりにも無知。

いやだからあなたが言うところの「その時点において考え得るすべてを洗い出し」た結果で言ってるんですかねこれだけ色んな人が具体的な事例で無理って言っている中で。

コンピュータの内部は西暦で処理されていますが、元号表記が必要な場合、「1989年1月8日からは平成」と変換しているだけのことです。それが次は「2019年5月1日からは○○」と新元号の処理を一行加えるだけです。

あまりにも無知。1行加える、というのは何に対してですかね。例えば1システム1行で済むと仮定したとしても100万システムあれば100万行なんですが。そもそもコンピューターの内部が西暦で処理されていますが、というのも大抵の場合嘘ですが（累積秒だよね）。

さらにこれらの制御は「フラグ」によって行います。あるフラグが立っていれば元号処理、または「新元号」を含んだ処理をさせ、そうでなければ通常処理という具合です。

サマータイムも同じく、「サマータイム」のフラグが立っていれば、サマータイムの開始日時を参照し、その切り換え日ならば、必要な時間調整をするというだけのもの。プログラミング初心者でもできる程度の処理です。

さっきは「こうした常識と知識を踏まえて、可能性をさぐる論理力が求められるからです。」とか言ってたんだけどさー。で、必要な時間調整をした後データとの整合性はどうやって取るんですかね。ここまでこの人データのデの字も言ってないけど。

一方で、ここがサマータイム導入が日本で難しいところに直結します。この記事を書いた読売新聞の記者のように、コンピュータへの無理解と、同時にコンピュータへの過大な期待が、日本社会にはあるからです。

お前が無理解だろ、と言いたくなった人が1000万人はいると思うぜ…

此処から先は蛇足なのでもういいかな。まあこの人の書いたものがすべて蛇足もいいところでしたが。

補足

で、結局どういうことなの、という声がありそうなのでちょっと補足します。わかりやすいとは限らん。

サマータイムの問題はシステムから見るとまず、時計がずれる、という問題があります。当該エントリで問題にしているのはおよそこの第一段階の問題が全てで、あとのことは「考慮しときゃできるでしょ」といっているだけで全く触れていませんので、そこが騙しポイントなわけですね。
で、時間がずれることを修正する、これは当たり前にできます（できなかったら欠陥品、というのは正しいけど、そんな欠陥システムないから）。そうすると何が起こるか。主に以下のことが起きます。

・データが示している時刻（データ内に持っている時刻、例えばXX予定時刻とかや、ファイルのタイムスタンプ等）とのズレ
・現実の時間とのズレ（サマータイムをまたいでバイトしたらバイト代が1時間分急に増えたり、働いたことが働いてないことになったり、してもよいです？）

が起きますね。時計の問題に関しては日時そのものをテキストデータでもっている場合と、コンピューター内時間（時計とは関係ない、全世界で一定の値）でもっている場合で大きく異なります。
後者の場合はわりと対応が可能なことも多いです。時差の対応なんてのはそういう話です。しかし、時差の問題とこの問題が違うのは、時差の場合、単純に1時間ずらす、ということで問題ないわけです。これは単純に相対的な関係の解消だからです。12:00に更新したデータが1時間時差のある国で見たら13:00に更新したことになっていた、という場合、これをいわゆる標準時（日本から9時間時差があるやつ）で見たら一緒、ということですね。でもサマータイムの場合、昨日12:00に更新したデータが今日になったら13:00時に更新したことになってた、というわけにはいかんのです。サマータイムを跨いだら時間が変わったように見えてはいけない。だから、サマータイムに対応するためには予めサマータイム適用日なのかどうかをデータとしても持って（ここがポイントね）、いまサマータイムかどうかを判定基準に、表示や更新で考慮を入れなきゃいけないわけです。
おおよそこの問題が「対応不能」なのは、この「いまサマータイムかどうかを判断する項目」をデータ項目としてもっていないシステムが多いからなわけです。

日本に閉じたシステム、という問題は、単に時差の問題すら解決が難しかったりしますが、現実のシステムでは時差で問題がでるのは表示だけのことが多いのでわりと対応可能です。サマータイムへの対応はこれとは次元が違います。日本以外でも、「コンピューター導入前にサマータイムが施行されていた」国以外では同様の問題を抱えているのでサマータイムを今更やり始める国はないと思いますね。

さらに

補足的なネタエントリ*2

*2：「サマータイムとグレムリン餌やり問題」2018年08月11日 『novtanの日常』
http://novtan.hatenablog.com/entry/2018/08/11/165328

執筆： この記事はnovtanさんのブログ『novtanの日常』からご寄稿いただきました。

寄稿いただいた記事は2018年08月13日時点のものです。