コンピューターシステムのサマータイム対応は大変なんだよ

つれづれ ― プレイバック より。

◇夏時間終了時点のコンピューター・ログの一時間重複は問題にならないのかしら？
　米国では、 11月第1日曜日午前2時に午前1時に直すので、 例えば夏時間中の 1:45 のトランザクションと標準時刻になったときの 1:15 （もちろんこっちが後） とでログのタイムスタンプが逆転することになる。 当日は一日が 25時間になったり、 システム上のエラー回避ルーチンがとてもややこしそう。 1:00 から 2:00 には全てのコンピュータを停止させちゃうのが一番カンタンそうですが、 そうもいかない??

ログそのものは標準時 ( 日本標準時でも世界標準時でも ) で記録しておけば、 一時間重複の問題は本質的には無くなります。
※ 読み出して表示するとき、 夏時間で表示しろ、 ということであれば、 夏時間期間中の分だけ 1時間加算して表示するだけ。 ( それでも、 それなりに面倒なんですが。 )

問題は、 時間計算が絡むときです。
たとえば、 24時間営業の有料駐車場。 仮に、 10分 100円として。
出庫時に清算して受け取ったレシートが、 こんなふうだったら…

  入庫時刻  xx年xx月xx日  1:10
  出庫時刻  xx年xx月xx日  1:15
  料金:   700円

※ コンピュータの内部では、 上のログの件で書いたように夏時間期間であろうと、 標準時で記録するようにしていたとして、 の話です。 そうしておけば、 料金はちゃんと計算できます。

このレシートを受け取った時に、 「5分だから 100円だろ!?」 と文句を言ってくるお客さんの顔が目に浮かぶようです。

日本では、 次のような表示にしないと、 おそらくダメでしょう。

  入庫時刻 xx年xx月xx日  1:10夏
  出庫時刻 xx年xx月xx日  1:15標
  料金:   700円

時刻の前か後ろに一文字追加してあげるだけのことです。 が、 その一文字分のスペースが無かったら… レシート発券機を交換することになるでしょう。

このように、 ソフトウェアの大改修だけでなく、 ハードウェアの変更まで必要になることもあるのです。

これは面倒だ、 ってことで、 切り替え日の 1:00 ～ 2:00 ( 夏時間の最後の 1時間だけ? ) は、 すべてのコンピュータシステムを止めてしまった、 としましょう。 ( 実際問題、 ムリですけど f(^^; )

それでも、 切り替え時間帯をまたがる時間計算は、 発生します。
たとえば、 夜勤の人のタイムカードに打刻された時刻。
出勤が 0:00 で退勤が 4:00 なら、 ( 途中に休憩を挟んでいないとして ) 労働時間は 4時間でしょうか?

コンピュータ内部では標準時で扱っているとしても、 データの入力時には、 それが夏時間なのか標準時なのか、 きちんと入れられないと、 この人の給料が 1時間分減ってしまったり増えてしまったりしてしまいます。
そのためには、 オンラインでデータ収集してしまうタイプのタイムレコーダなら、 おそらくソフトウェアの改修だけで済むでしょう。 ( それだけでも、 ソフトの改修の手間はタイヘンですけど。 f(^^; )
しかし、 タイムカードに印字しておいて、 あとからコンピュータに手入力する場合。 入力ミスを減らす観点からも、 タイムカードを 「証拠」 として扱う観点からも、 タイムカードの印字に夏時間か標準時かを識別する記号が付いていないと困ります。
そうすると、 タイムカードの時刻にも 1文字ずつ余計に印字するスペースが必要になり… タイムレコーダを買い換えざるをえなくなるでしょうね。

まとめると。
ソフトウェアは、 夏時間の時刻データを入出力する部分は、 すべて改修対象。 時間計算をする部分も、 おそらくかなりの範囲で改修が必要。
ハードウェアには、 時刻の表示で夏時刻と標準時が識別できなければいけないものがあり、 それは改修 ( というか、 買い替え ) しないといけない。

※ ちなみに、 パソコンの Windows では。
Windows 自体は、 いちおうは夏時刻に対応していますので、 ( 自動更新をやっていれば ) 自動的に時刻表示は切り替わりますし、 ファイルのタイムスタンプの前後関係が入れ替わったりすることもありません。 ただし、 夏時間と標準時の切り替え日については過去の履歴を持っていませんので、 過去の時刻の表示が正しくなくなる可能性はあります。
また、 メールソフトなどの時刻がどうなるかは、 それぞれのソフトが夏時間に対応しているかどうかによります。