オルタナティブ・ブログ > Software Development >

ソフトウェア製品開発現場の視点

コンピュータによる「夏時間」の扱い方についての解説

»

前回のブログで、コンピュータソフトの問題で日本で「夏時間」を採用するのは難しいということを書いたところ、わかりにくいという指摘を受けました。確かに説明不足でしたので、すこし詳しく解説してみます。

現在の多くのコンピュータは、内部に時計を持っています。厳密に言うと複雑になるのですが、説明上、Windows や Mac OS などが時間を知っていると思ってください。たとえば、Windows では、一番右下に時刻が表示されており、その時刻をクリックするとカレンダーが出てきます。

Clock

私の Windows の設定の事情で、月や曜日が英語で表示されていますが、通常は日本語で表示されます。このときに、1:05:49AM と表示されているのは、日本の時刻です。

もし、このコンピュータを持ってカリフォルニアに行って、時刻を表示したらどうなるでしょうか? 何の設定変更もしなければ、このコンピュータは「日本時間」での時刻を表示し続けます。短期間の滞在なら、まあ読み替えて使えばいいかもしれませんが、カリフォルニアの時間に合わせたほうが便利です。

日本とは時差がある場所に行ったときの設定変更は、「コントロールパネル」⇒「時計、言語および地域」⇒「日付と時刻の設定」で行います。以下の画面を参照してください。

Dateandtime

この画面には、「日付と時刻の変更」と「タイムゾーンの変更」の2つのボタンがあります。上のボタンは、コンピュータの時計の時刻を変更するボタンです。しかし、カリフォルニアに行ったときには、このボタンではなく、「タイムゾーンの変更」ボタンで変更します。

なぜこのような複雑なことになっているかというと、コンピュータの時刻の持ち方に原因があります。コンピュータは、時刻を UTC (世界標準時) を持っています。しかしそのまま表示すると不便なので、指定したタイムゾーン分だけシフトして表示します。上の画面では、「時刻」に12:49:31 AM と表示されていますが、コンピュータ自体は、この時刻を UTC で前日3月30日の 3:49:31 PM であるという情報と、「大阪、札幌、東京」という場所は、UTC よりも9時間進んでいるという情報を持っています。そして、その結果として、12:49:31 AM が現在いる場所の時間が表示されているということです。上の「日付と時刻の変更」ボタンは、UTC の時刻自体を変更する機能です。カリフォルニアに自分が移動しても、UTC は変わらないので、「日付と時刻の変更」ボタンを使ってはいけません。

では、日本で夏時間が導入したらどうすればよいでしょうか? タイムゾーンは変わらないので、「タイムゾーンの変更」ボタンでもないでしょう。良く見ると「タイムゾーンの変更」ボタンの下に気になる記述があります。「このタイムゾーンでは夏時間は実施されていません」と書かれています。試しに、「タイムゾーンの変更」ボタンを押して、カリフォルニア時間に変えてみます。カリフォルニアは、「太平洋標準時 (米国およびカナダ)」ですので、これを選びます。

Pdt

OK を押すと、先ほどの「夏時間は実施されていません」という表示が、「夏時間は、Sunday, November 06, 2011 - 2:00 AMに終了します ...」という表示に変わりました。Windows は「夏時間」がいつ始まって、いつ終わるかのルールもすべて持っていて、夏時間と冬時間の間が入れ替わるときタイミングで、「表示される」時刻を勝手に変えてくれます。もし正式に日本で夏時間が採用されると、マイクロソフトの定期アップデートによって、Windows に日本の夏時間がルールが入って、そのルールに従って時刻が表示されることになります。重要なのは、UTC は地球上のどこに行っても、夏時間が採用されるされないに関わらず不変ということです。ここでは、Windows で説明しましたが、Mac OS, Linux, Unix などの OS でも時刻はほぼ同様に扱われています。

今回夏時間の採用で問題となる原因は、アプリケーションソフトウェアの作り方です。ソフトウェアの多くは中で時刻を扱っています。日本では経験上、多くのプログラムはローカルタイム、すなわちその場所の現在の時刻を使っています。なぜなら、そのほうがプログラムを書くのが簡単だからです。そして、ほとんどの場合時刻が「前に戻る」というケースは考慮されていません。たとえば Suica は、改札を入った時刻と改札を出た時刻が記録しますが、改札を出た時刻が入った時刻よりも前だった場合の動作は、おそらく「不明」です。それは、日本のように時差もない、夏時間もない環境だと、そのような状況が想定されていないからです。Suica の例は、私の想像も含まれていますので、実際は問題がないかもしれませんが、時刻が「戻る」という場合でも正しく動作するかは一つ一つ検証が必要です。

国の中に時差があったり、夏時間をすでに採用している国や、世界中で使われているソフトウェアでは、プログラムの中の時刻は UTC が使われています。UTC を使えば、「時刻は前に戻らない」という前提でプログラムが作られていても、問題ありません。

Comment(8)

コメント

なが

わざわざ追加解説していただいて恐縮です。

>たとえば Suica は、改札を入った時刻と改札を出た時刻が記録しますが、改札を出た時刻が入った時刻よりも前だった場合の動作は、おそらく「不明」です。それは、日本のように時差もない、夏時間もない環境だと、そのような状況が想定されていないからです。

けれど、この個所読んでますます分からなくなりました。Suicaがローカルタイムのままなら改札を入った時刻も出た時刻も夏時間に影響されないからあべこべになるなんてこと有り得ないと思うのですけど。
仮に7月1日午前0時ジャストから夏時間が実施され、その時間が6月30日午後11時に変更されるとしますと、ある人が変更前の午後11時50分に改札口に入ったとします。20分後改札口を出ると午後11時10分になりますが、コンピュータの時計はやっぱり午前0時10分でしょうから問題ないんじゃないですか?

ame

>コンピュータの時計はやっぱり午前0時10分

上の解説でOSが「タイムゾーン:東京」で夏時間も考慮するようになると、

出札側コンピュータのローカル時刻は6/30 23:10となります。

そして、Suicaに打刻された入札時のローカル時刻をUTCに変換後
出札側コンピュータのUTC時刻と比較しなければ、
正確なタイムスパンは求まりません。
(Suicaに正確なタイムスパンが必要かどうかは知りませんが)

これが、列車や飛行機の運行システムだと正確なタイムスパンが必要です。

現在ローカルタイムでプログラムしてるところを、
全てUTCに焼きなおすとなると、
2000年問題より複雑な問題と思います。

とても、1年や2年で対応できるとは思えません。

ところで、冬時->夏時は
7/1 00:00->6/30 23:00に戻るのではなく、
7/1 00:00->7/1 01:00に進むのでは?

名無し

容易に想像できるか否かは、携わったことが有るか無いかかもしれません。
(すみません、ブログで一般公開される内容なので、匿名をお詫びします。)

下記も確認しておりますが、私は「サマータイム導入案」を聞いて怖くなりました。
http://blogs.itmedia.co.jp/takeuchi/2011/03/post-92d4.html

今はサマータイム導入が否定的になっている点から一安心です。

もし、導入されたら、下記から、恐らく、2000年問題より
酷いことになると考えます。それこそ、倒れる人が…。

[1]夏場までに時間が無く、影響度が大きいと考えられること
(変更は?テストは?コストは?誰がお金を?)
[2]計画停電の影響がある状態で、IT関連にリソースが少ない場合も
考えること。

おっしゃる様に、「あのシステムはサマータイム導入済み。
でも、こっちは導入未」なら、混乱が発生する可能性が大でしょう。


ところで、夏に向けて、下記は影響しないのでしょうか?

計画停電のための通信量減少(メールなら、HTMLやデコメールよりPlainを)
 通信量が多い⇒電気を余計に使う ではないのでしょうか?

HDDの熱対策(熱暴走は、HDDだけではありませんが)
不安定なHDDや過度に熱を持ったHDDで、障害にならないのでしょうか?

http://gigazine.net/news/20070219_disk_failures/
> Googleによると、ハードディスクは温度や使用頻度に関係なく故障する

> ただし、ハードディスクの温度が50度を超えるような環境であれば、
> 故障率は如実に上昇しています。これはハードディスクのメーカーも
> 推奨していない温度なのでさすがに当然か。

HDDレコーダー, HDD内蔵テレビなどもあります。
これらで、S.M.A.R.T.情報を取る方法は分かりません。

ながさん、

さらに混乱させたようで、説明不足を反省しております。ame さん、説明ありがとうございます。ameさんにも説明していただきましたが、私なりに説明したいと思います。Suica の例はフィクションですが、説明のために使います。

コンピュータの基本となる時間は世界標準時の UTC なのですが、そのコンピュータで動くプログラムは、UTC を見て動作するか、ローカルタイム (日本の場合は日本標準時) を見て動作するかは、プログラムを書く人次第です。残念なことに、何も考えないでプログラムを書くと、日本標準時を使うプログラムができてしまいます。これまでは日本標準時は、時間が「前に戻る」ことがなかったため、問題がなかったのですが、夏時間を採用すると、夏時間から冬時間に移る日に時間が前に戻るケースが発生します。ながさんの例では、11時50分に改札を入って、11時30分に改札から出るケースが発生するということになります。きちんと世界標準時を使ったプログラムを作っていれば、この問題は発生しません。ameさんの指摘の通り、冬時間から夏時間へ変わるときには、時間は進みますので、より問題あ大きいのは、夏時間から冬時間になって時間が前に戻るときですね。

名無しさん、コメントありがとうございます。

通信量を削減することが、電気使用量の削減にどのくらい効果があるのか、ちょっとわかりません。仮に、通信量を削減することで効果があるとしても、HTML を Plain にすることでの削減は期待できないと思います。なぜなら、私のメールボックスのデータ量を増やしている主な原因は、添付ファイルだからです。添付ファイルをなくすことは、通信量の削減に効果があると思います。

HDD の熱による影響は確かに気になるところですね。冷房が効かない状況でコンピュータを動かし続けるのは、避けた方が良いように思えます。停電すれば、冷房も動かないですが、コンピュータも動かないので、良い訳ですが、停電が終了した直後の温度の上がったコンピュータルームで、サーバーの再立ち上げというようなことも発生すると思います。サーバーを止めたり動かしたりするだけでも悪い影響が出ると思いますが、それに高温という問題が重なってくるので、HDD の故障に対する備えをしておいた方が良いように思います。

名無し

こちらこそ、コメント有難うございます。

> 主な原因は、添付ファイルだからです。
> 添付ファイルをなくすことは、通信量の削減に効果があると思います。

下記の点より、チェーンメール同様に、計画停電中は、無闇に通信することで
パソコンや携帯などで通信料及び電気量を増やすことは良くないと考えました。

[1]HTMLメールの通信量は、Textの3倍~5倍と言われる(伝聞表現にご注意)。
3倍の知見は以前よりありましたが、5倍は初耳でした。
「外部へのメールは複数のSMTPサーバを介しますし、Textで削減できるなら
トラフィックや電気量は削減できるのでは?」と私見で考えました。
[2]
http://www.itmedia.co.jp/promobile/articles/1008/17/news044.html
> 世界のモバイルデータ通信、1年でトラフィックが約3倍に
http://gigazine.net/news/20100604_sbm_traffic/
> ソフトバンクの通信量の半分をユーザーの2%が占拠、通信量増大は
> 「携帯事業会社の経営者の悩み」
http://o-kaz.dreamblog.jp/blog/515.html
> 昨年9月時点の携帯端末のデーター通信量は毎秒71ギガビット(ピンときませんが・・)
>  1年で64%の激増
>    (総務省が発表した統計)
>  スマートフォンの普及で動画など無線データ通信が急増しているため。
http://www.atmarkit.co.jp/fwin2k/win2ktips/244eliminatehtml/eliminatehtml.html
> HTMLメールをテキスト形式で読み出す
> 「イメージなどが入るとデータ・サイズも大きく
> なってうっとうしいし、携帯電話など一部端末では
> 正しく読めない、そもそもスクリプトなどを使った
> クラッキングの危険性もあるのでやめてほしい」と
> いう人もいる。
> テキストだけでも十分意思疎通ができるはずなのに、
> 余計な装飾などで無用なトラフィックやディスク領域
> の占有を招く(のが許せない)から、というところだろう。
[3]自分で、signatureのみ+添付メールを送受信して確認したところ、
ファイルサイズ及び送受信のバイト数(通信量は、エンコード
された1.5倍程度)は、HTML, テキストであまり変わりませんでした。

「暇だから(目的も無くの意)、ネット, 携帯やTwi○ter」と言うのは
計画停電では考え物かもしれません。

なが

ameさん、確かに夏時間だと早まりますね。私どうも方向音痴ならぬ時間音痴みたいですみませんでした。
私の素朴な疑問は、コンピュータ内時間だけは通常時間のままにして非コンピュータ時間だけ夏時間にできんもんかなあ、と思った次第です。
例えばの話、NHK7時のニュースで「テレビ画面の表示は通常時間で5時ですが7時のニュースをお送りします」とか言って、お断りすれば、一般の人もそのうち慣れるでしょうから。駅のダイヤだって同じようにすればいいとか。そんなこと考えています。

ame さん。HTML メールが悪いのではなく、HTML メールにリンクが入っていて、アクセスが増えるのが問題だと思います。ネットワークのトラフィックが増えるとどのくらい使用エネルギーが増えるのかは、私は、ちょっとわかりません、

ながさん。自主的に1時間や2時間早く活動するというのは、良いと思います。何年か前に札幌でやっていたように記憶しています。その結果については、聞いていませんが、参考になると思います。

Yoshi

こんにちは。私もこの話が出るたびに、やっかいなことになるなと思っていました。多くの人が指摘していますとおり、日本では2000年問題よりよっぽどややこしいことになると思います。多くの先進国で夏時間が採用されており、オペレーティングシステムも対応しているのだから、できるはずという意見も多くありますが、実のところはそう簡単にはいかないでしょう。

日本ではあまり話題にならなかったと思いますが、アメリカでは Year 2007 Problem と言って、夏時間の期間が変更になったときにかなりの作業が発生しました。主要ソフトウェアベンダーは2年くらい前からソフトウェアの検証や、必要なパッチ、移行ガイドの準備、ユーザー環境での検証のヘルプなど。夏時間の期間が変更になるだけでこれだけ準備が必要になるのですから、いままで夏時間が使われていなかった日本で夏時間を施行するには更に長い準備期間がいると思います。

とくにややこしいのはカレンダー&スケジュールに関するソフトウェアです。たとえば、行事の予定などは通常ローカルタイム(例えば、8月20日の午前10時から)で作成しますが、多くのソフトウェアは日時をUTCに標準化して内部に保持します。夏時間が採用になった場合、今まで保存されていた情報を更新する必要が出てきます。このデータの移行は、ユーザー環境の夏時間パッチの適用と同時に、一気にやってしまわないと矛盾が生じることになります。

また、いまだに企業内で多く使われている Windows XP などの古いシステムでは、夏時間の適用をある年度以降のみ有効にすることはできません。つまり、もしこのようなパッチを適用すると、夏時間が適用されていなかった前年の日時の表示に影響がでます。この問題自体は、Windows Vista/2003 以降で解消されましたのですが、マイクロソフトも互換性のために随分苦労しているようで、いまだ標準時のシフトや、夏時間が次の年まで続くようなちょっと例外的なパターン(最近のトレンドで、暫定的に夏時間をそのまま続行するような地域がいくつかあります。ごく最近の例ではロシアで10月末に冬時間に戻さないという法案が可決されたようです)は対応できていません。(現在のマイクロソフトの実装では、1年のうちに時間の移行がないか、ないしは2回である必要があります。夏時間が継続するようなケースでは、2回目の移行を12月31日の23時59分59秒に設定することで、問題を回避しているようですが)

コメントを投稿する