blogos.com
結論から言って筆者の宮脇睦なる人物はほぼド素人と断じて良い。
PCやスマホ等のアプリを単独でひとりでコーディングした経験はあるかも知れないが、一定規模の情報システムの開発および保守の経験はないと考えられる。そうでなければ、こんなアホなことを堂々と述べ奉ることはできないですよ。
ほぼド素人の言説をいちいち検証なんてバカバカしいから、ポイントポイントを指摘していく。
ホストコンピュータなどと接続していて、連続した情報をやりとりしているシステムなら、バチっと電源を落として、その後の立ち上げで日時の変更をすればよいだけのこと。
スマホのアプリが挙動不安定になったら、そりゃそれでどうにかなりますわね。PCでも再起動かけりゃあ、大抵どうにかなりますわね。でもね。いきなりサーバの電源をバチッと落としたら、いまどき大問題になりますよ。
さて、それなりの規模の情報システムのホスト、サーバがどのように時刻を管理しているかを考えてみよう。銀行なんかは勘定系という重厚長大なシステムを組んでいるので、もっとライトな、たとえばメールのサーバを考えてみよう。
誰しも Gmail ぐらいは使うだろう。実際のところ、メールというものには発信者や時刻、配信を経由したサーバ等の情報が細かく書かれていて、Gmail いちいち細かい情報は表示しない。けれども見ようと思えば表示できる。
私の Gmail アカウントに届いた ZOZOTOWN からのメールを見てみる。画面には8月9日とだけ表示されている。その詳細な時刻情報を見てみたら：
Date: Thu, 9 Aug 2018 13:41:03 +0900 (JST)
PC やスマホ、サーバなんかでは、1970年1月1日00:00をゼロとして、ここから何秒経過したかを64ビットで表現する。
古いシステムでは32ビットで表現してたけど、この場合2038年1月19日03:14:07でいっぱいいっぱいになる（2038年問題）。いま動いてるシステムは64ビット化したり等で対応済み、のはず。
ちなみにこの時刻はUTC（協定世界時）、昔はグリニッジ標準時と呼ばれたもので、要はイギリスのグリニッジ天文台が中心の時刻。もちろん世界各国には時差があり、UTCプラスの9時間が日本標準時(JST)。
このメールの時刻の詳細情報は「2018年8月9日（木曜）13:41:03、これはUTCプラス9時間のJST表示」という意味になる。
電波時計は時間が進んだり遅れたりということがあんまりない（実は時計側が意外にアバウトだけど）。これは福島と九州と2か所から時報電波JJYが発射されていて、電波時計はどちらか強い方の電波を拾って、自動的に時計合わせをやる。
東日本大震災のとき、福島の電波の送信所が避難指示区域になったものだから電波が2か月ちょい止まったり発射されたりの繰り返しで、日本東部一帯の電波時計も時刻合わせが困難でメタメタになった。
さらに余談。韓流アイドル三人組でJYJっているけど、最初はJJYだったのが（2009年）、いつの間にやらJYJになった。あれたぶん、芸能プロダクションがJJYを商標登録しようとしたけど、電波時計の電波JJYを所轄する総務省がクレームを付けて断念したんだよ。公共のテレビ・ラジオの電波に、別の公共の電波の名前JJYが流れるのって、さすがにマズいもんね。
PCやスマホは普通ネットワーク経由で時刻情報を流すNTPサーバというものに接続し、定期的に時刻合わせをやっている。いまどきメールのサーバだってそんなだ。
日本では情報通信研究機構の ntp.nict.jp が標準だけど、Windows の場合なぜか time.windows.com なんてサーバになってたりする。日本国内なんだか外国なんだか、どこにあるサーバなのか分からない。もし外国にあるサーバなら時刻合わせで通信のタイムラグが出るし、正しく修正するのにその分だけ手間がかかったりする。だからもし自分で設定できるのであれば、私は ntp.nict.jp を推奨。
その時刻合わせにしたって、システムに電源を投入したら1970年1月1日の09:00:00なんて場合は、いきなり正しい時刻に合わせるものだけど、普通はジワジワと合わせる。NTP のジワジワ合わせモード（slewモードと言うそうな）では1秒間で最大0.0005秒ずつ合わせる。もし0.1秒ズレていた場合は200秒、1秒ズレてた場合は2,000秒（33分20秒）かけて合わせる。
このように、そこいらのメールのサーバですらシステム内部での時刻表現やら、時刻合わせのやり方やら、けっこう複雑なのよ。ま、システムの管理・運用・保守では常識の範囲内だけどね。
この記事の筆者は、このレベルの知識すら持ち合わせていないと断ぜざるを得ない。
さて、と。
コンピュータの内部は西暦で処理されていますが、元号表記が必要な場合、「1989年1月8日からは平成」と変換しているだけのことです。それが次は「2019年5月1日からは○○」と新元号の処理を一行加えるだけです。
これは正しい。間違いなくその通り。ただし。それは自分が作ったアプリやシステムで通用する話。
世間ではバブルの頃に組んだシステムがいまだ普通に動いてますから。1989年1月8日の平成改元のときのシステムが、ね。
もちろん当時の人たちは明治・大正・昭和の対照表をコードの中に入れ込んでて、それに平成を追加したことでしょうよ。
さて、それやった人が当時30歳だったとしたら、今は60歳とかだ。バブル崩壊で行方不明、ヨソに転職、生き残ってお偉いさんになってる、早期退職でIT業界を離れてる、などなど。
そういう人たちが膨大なコードのどの部分にそれを入れ込んだかを、現役の現場の人間がどうやって探し当てれば良いのだ？と。「あの件、どこの部分で元号処理やってるんですか？」って、やった本人に聞こうにも、本人が行方不明じゃあ、どうにもならない。お偉いさんになってたら、知らんとか忘れたとか言われるならまだマシ、普通いちいちオレに聞くなボケなんて罵倒されるのがオチ。
当時のことだから「仕様書」というモノがあるにはある。紙に印刷された仕様書が段ボール箱のひとカタマリとなって、どっかに保管されている。まず倉庫の段ボールの山の中から、仕様書の段ボール箱のカタマリを発掘しなければならない。そこから、いちいち印刷された仕様書に目を通して、当該部分を探し当てなければならない。
もう、ね。遺跡や化石の発掘の現場とおんなじ状況な訳ですよ。
そういう事情をすっ飛ばして「一行加える」って、それは業界の現実を知らないド素人の言いぐさです。
私もプログラミングの経験があるにはあるので。自分だったら…まずアプリの開発段階で対照表を作っといて、起動のたびに対照表を読み込む仕様にしておく。現時点でまだ新元号が明らかになってないから仮に、2019年5月1日から「ゲボボ」とか置いといて、アプリのアップデートで「改元準備」ということで（明確に言っても言わなくてもいい）対照表を配信しておく。
もし言ったとしたら、PCなりスマホなりの日付を手動で2019年5月1日に設定する人が絶対にいる。そんでアプリで元号が「ゲボボ」と表示されたらバズるかも知れない（笑）。バズるかどうかはともかく、そういう人がいてくれた方が配信側としてはありがたい。改元対応が本当にうまくいきそうかどうかのテストになるので。
そいで新元号が発表されたらゲボボを新元号に差し替えた対照表を配信すれば良い。
ただしこれは自分でスマホとかのアプリを作って自分で配信する場合に通る話であって、一定以上の規模の企業の情報システム・アプリの場合、こんなに簡単にはいかない。ふつう改元は想定してないから、たいていは対照表じゃなくてコードの中に突っ込んでると思う。もう、ね。発掘現場そのものですよ。
んで記事の話題はサマータイムに飛んでる。
普通のOSはサマータイムに対応している。でもそれは、こんだけITモノが普及する以前からサマータイムやってる国・地域が多いものだから、OSのレベルで地域ごとのサマータイムに対応しているというだけの話で、新たに導入するとなると話が違ってくる。
だいいち今般のサマータイムは2時間だ。たいがいの国・地域でサマータイムは1時間だ。そうでない国・地域もあるけど、それは昔からそうなのだから、OSでも最初っからそのように対応させている。
新たにサマータイムを導入ってだけでもオオゴトなところを、加えて2時間というのは、いくら何でも無茶だ。
いまどきOSはグローバルで開発するもの。百万歩ゆずって2019年・2020年の2年間限定で日本だけ2時間のサマータイムって…グローバルな開発体制で日本という、相対的に人口の少ない地域のためだけにそのように対応させるなんて、みんなソッポ向きますですよ。
時報電波JJYに話を移す。JJYは一秒に1ビットの情報を発信している。1分間の60ビットで、年月日と時刻を流している。ほかに、うるう秒なんて情報も乗せてる。60ビットをフルで使っている訳じゃなくて、10ビット使ってない。この10ビットは「常にゼロ」という仕様。実際に使われてるのは50ビット。
サマータイムについては、50ビットのうち2ビットが「予備」としてキープされている。
ひとつのビットはサマータイムの予告。現状は常にゼロだけど、仕様上は6日以内にサマータイムが始まる／終わるという場合はイチにするということになっている。
もうひとつのビットは、これまた現状は常にゼロだけど、ただいまサマータイムの真っ最中ですよという場合にイチとする仕様になっている。
どこに「サマータイムは2時間」という情報を入れ込め、と？グローバルにサマータイムは1時間がスタンダード。だからJJYの電波仕様もサマータイムの予告と、サマータイムの真っ最中情報しか織り込んでいない。おそらく仕様を作るとき、サマータイムは1時間と想定していたのだと思う。
理論上は10ビットの空きがあるから、そこに入れることは可能っちゃあ可能だ。
問題は、電波時計は工業製品である。ある程度の量をまとめて開発し製造するというシナモノだ。せいぜい2年間の、グローバルに見てもイレギュラーなサマータイムのために製品を開発して製造し売り出すっての、時計メーカーとしてはぜんっぜん割に合わない。2年間のため専用の電波時計をわざわざ買う消費者はいない。JJYを発信してる国立研究開発法人・情報通信研究機構の中の人たちも、そんな仕様変更わざわざやるほどヒマじゃない。
技術的にもマーケティング上も、2時間のサマータイムは無理筋にも程がある。手動で時計を2時間調整しろ、と？それじゃあ電波時計を使う意味がない。お話にならない。
ダメですな。
