「「サマータイム導入はコンピュータシステム的に難あり」は本当か」は本当か
引用元は以下となる。最終訪問日: 2018/8/14 19:27
https://www.mag2.com/p/news/367461/3
https://www.mag2.com/p/news/367461/4
上記内容について考えたことを簡単にまとめる。
こちらの勘違い、解釈の誤りなどがあればご指摘いただければ幸いである。
コンピュータ（システムやプログラム）には「時間経過」の概念がありません。命令を受けた瞬間からの経過時間は、秒単位でカウントアップしていくだけで、つまり「その瞬間」しかコンピュータは認識していません。
これをプログラミングにより擬似的に、時間経過の概念があるように見せかけているのが、エアコンなどの「タイマー機能」です。
「時間経過」の概念がない、といいつつ、経過時間を秒単位でカウントアップしていく、は矛盾に見えます。また、プログラムには時間経過の概念がないはずなのに、プログラミングで概念があるかのように見せかけている？というのは一体何を意味しているのかよくわかりません。
一般的なlinuxにおいては、jiffiesという時間経過の概念があり、これは秒単位でのカウントでもない。
Jiffies は、tick、すなわち 1/HZ 秒 (RHEL では HZ = 1000で、1 ミリ秒) 毎に 1 ずつ増えるグローバル変数 (符合なし整数) で、カーネル内部で時間を測るのに利用できます。
サマータイムとなり自然時間の定義が変われば、コンピュータも同時に変えなければと「思いこみ」ますが、コンピュータが処理に用いているのは、埋め込まれたクォーツが刻む「内部時間」だけです。
日時の処理は、内部時間を変換して行っているに過ぎず、自然時間の概念をコンピュータは必要としません。
コンピュータは自然時間の概念がなければ、内部時間を自然時間から/へ変換することができないのではないか？
まず、前提条件を確認する。人間はわざわざタイムゾーンがどちらであるかを判別したくないため、自然時刻で入出力したい。
- 人間は、人間可読性のある自然時刻しか入出力できない。
- コンピュータは、人間可読性の無い内部時刻しか処理できない。
次に、実際のデータの流れをまとめる。
・人間は、自然時刻を、コンピュータへ入力する。
- コンピュータは、自然時刻を内部時刻に変換する。
- コンピュータは、内部時刻を処理する
- コンピュータは、内部時刻を自然時刻に変換する 。
- 人間は、コンピュータが出力する自然時刻を読み取る。
例えば、2019年7月1日~9月30日まで2時間前倒しにすると仮定する。この場合１分毎に日付と時刻は以下のように変化すると想定される。
| 日付 | 時刻 |
|---|---|
| 2019年6月30日 | 23:57 |
| 2019年6月30日 | 23:58 |
| 2019年6月30日 | 23:59 |
| 2019年7月01日 | 02:00 |
| 2019年7月01日 | 02:01 |
ここで「2019年7月1日、 01:59」の自然時刻で入力された場合、コンピュータは内どう処理すべきだろうか。
(a) 2019年6月30日 23:59 とみなす
(b) 2019年7月 1日 3:59 とみなす
(c) 2019年7月 1日 2:00 とみなす
(d) エラーにする
いずれの選択をとってもコンピュータは、どの値域が有効な自然時間であるのかを理解する、すなわち、自然時間の概念を必要としててしまうのは明らかである。
コンピュータは考え得る限りの状況をテストしてから製品となり、日時を扱うシステムなら「2100年に2月29日はあるか」という処理までチェックするものです。
<略>
プログラミングとは、その時点において考え得るすべてを洗い出し、対応できることは対応し、将来、予想されることに備えておくものです。
コンピュータは考え得る限りの状況をテストとする点がポイントになる。これはすなわち、テスターが想定していない使い方はテストできないことになる。
例えば、電化製品の場合、想定している寿命は長くても15年でしょう。それなのに、2100年が設定できるかどうかをテストしたならば、テスターが本体製品仕様で想定されない無駄なことをしているといわざるを得ない。
日本国内におけるJSTをいじくるレベルでのサマータイム対応は、おそらくここ数年間で予見できた人間はいないのではないか。あらかじめ計画されたものではないことも考えると、いないと考えることに無理はない。
想定できない問題に対して、事前に想定しろということは、無理難題になってしまう12 。
サマータイムも同じく、「サマータイム」のフラグが立っていれば、サマータイムの開始日時を参照し、その切り換え日ならば、必要な時間調整をするというだけのもの。プログラミング初心者でもできる程度の処理です。
これ「日時」を表示させるだけのプログラムならばともかく、現実的には自然時間の入出力や計算が入ると、単純な問題にはならない。
例えば、時間が連続的でなくなる点について、どのようにユーザーへ表現すべきか、などの実際に起こりうるケースが十分考慮できていない。この場合、データ欠損と誤解されないためにはその部分を飛ばすなど、また新たな処理を追加せざるをえない。
プログラミング初心者レベルの単純な「おもちゃ」であれば、おそらくそこまで難しいプログラムにはならない。だが、現実に存在する「システム」を考えると、単純な問題であると結論付けるのは難しい。
所感
「無理にコンピュータのシステムを成さずとも、人力でやれば対応できる」という主張は読み取れた。
すべてのものを対応せずとも、人の柔軟性を生かせば必要コストは削減できる、という主張は理解できる。
しかしながら、基本的に想像や予想に基づいた記載内容が多い。また、技術的裏付けが乏しい、あるいは、誤解を招く表現に見える部分も少なくない。そのため、これらの事象は本文章の主張の裏付けになっていない。
現場において、具体的な課題は何か確認したうえで、主張を訴えるに値する根拠があるか、再考することを提案したい。