最近、サマータイムを導入するべきかどうかの議論が盛んですが、どうも、一般的なコンピュータ（Windows や Linux）の文脈で「時計を合わせる」という考え方があるようです。
端的に答えだけ言うと、一般的なコンピュータにおいて 時計を進めたり戻したりすることはありません し、するものでもありません。
なお、きわめて単純なマイコン（例えば電子レンジやエアコン、炊飯器の時間など）はこの限りではありません。
コンピュータの日時管理
現代の一般的な PC において、ある時点を起点として、サマータイムの実施の有無にかかわらず、一定の間隔（典型的には1秒）で数え続けるのが普通です。
といっても、普通の人には意味がわからないと思います。
現在、一般的に使われているOSでは、（日本時間の）1970年1月1日 午前9時ちょうどからの経過時間を秒単位で保持し、加算しています。
その時間からずっと止まらないストップウォッチだと思ってもらえば良いでしょう。
0秒
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━→ ずっと未来までつづく
1970/1/1 9:00 ↑現在
じゃあ、今が何秒なのかというと、このくらいです→「1534233950」
この数字は、「ユニックス時間」などと呼ばれていて、世界で共通の値です。
「世界で共通」というのはどういう意味でしょうか。
「今、この瞬間」、日本では「ある時刻」ですが、例えばアメリカでは「別のある時刻」です。
「ある時刻」といってもわかりづらいので、具体的にしましょう。
- 日本（標準時）: 2018年8月15日 12:00
- 欧州・中央（夏時間）: 2018年8月15日 5:00
- 米国・ニューヨーク（夏時間）: 2018年8月14日 23:00
- 米国・ロサンゼルス（夏時間）: 2018年8月14日 20:00
- 協定世界時 : 2018年8月15日 3:00
これらは、同じ瞬間です。ユニックス時間では 1534302000 です。
さて、誰かが何かをした――たとえば、今あなたがツイートした、あるいは何か商品を購入した――時間というのは、今あなたが生活している時間にかかわらず同じ瞬間のはずです。
現在、中央欧州夏時間と日本時間の差は（上述の通り）7時間ですが、今ツイートしたものが欧州で7時間後にやっと表示されたりはしません。当たり前ですが。
ただし、「見た目の表示時刻」は異なります。私たちが「12:00」に起こしたイベントが「5:00」に発生したように表示されます。これは見た目は違いますが、同じ瞬間です。
コンピュータでの時刻の管理はこういった形が基本になっています。
例えば、「ファイルの作成日時」などはそうなっています。
試しにやってみるといいのですが、
- ファイルを作成する
- プロパティから作成・更新日時を確認する
- 設定やコントロールパネルからタイムゾーンを別のところ（例えば欧州のお好きな国や米国など）に変更する
- もう一度同じファイルのプロパティを確認する
という手順を踏むと、別の日時が表示されると思います。それは、時差を考慮すると、同じタイミングを指しています。
このことから、内部では「（表示上の）時刻」を見ているわけではなく、「ある瞬間」を保存していることがわかります。
サマータイムに合わせて「時計を変える」ということ
今、サマータイムが突然開始されて、2時間進んだとしましょう。
あなたは、慌てて設定から「時刻の変更」を選んで時計を2時間すすめました。
たぶん、「PCの時計を進めればいい」と言っている人はこういう感覚だと思います。
さて、先ほどの長文を踏まえて、この対応は正しいでしょうか。
答えは、もちろん正しくありません。
今、たぶん世の中の時刻はこうなっているはずです。
- 日本（二重夏時間）: 2018年8月15日 14:00
- 欧州・中央（夏時間）: 2018年8月15日 5:00
- 米国・ニューヨーク（夏時間）: 2018年8月14日 23:00
- 米国・ロサンゼルス（夏時間）: 2018年8月14日 20:00
- 協定世界時 : 2018年8月15日 3:00
これらは先の例と変わらず「同じ瞬間」を指しているはずです。
そして、「時計を2時間進めた」日本の人の時計はこうなってしまっています。
- 日本（標準時）: 2018年8月15日 14:00
- 欧州・中央（夏時間）: 2018年8月15日 7:00
- 米国・ニューヨーク（夏時間）: 2018年8月15日 1:00
- 米国・ロサンゼルス（夏時間）: 2018年8月14日 22:00
- 協定世界時 : 2018年8月15日 5:00
これは世界の時刻との整合性が取れなくなってしまっています。あいつら、未来に生きてんな というやつです。2時間進んでしまっています。
正しい対応の方法
普通のOS（雑な言い方）では、「この地域では、協定世界時に対して何時間ずれた時刻で生活をしている」という情報を持っています。
これを一般に「タイムゾーン情報」とか「時間帯情報」とかいいます。「tzdata」とかもいいます。まあ、何でもいいです。
雑に言うと、「協定世界時との時差」の情報を全世界分持っています。
また、すでに夏時間が導入されている国や地域などでは、「いつからいつまで夏時間」という情報も同時に持っています。
過去に実施されていた「日本の夏時間」にも対応したデータがあります。
夏時間以外にも、「標準時の変更」の情報もこれに含まれています。
例えば、北朝鮮の標準時が +9:00 から +8:30 になって +9:00 に戻った情報も記録されており、（仮に北朝鮮の時刻で表示しようとすれば）正しく反映されます。
コンピュータは、このデータベースと、（たぶん記憶にないと思いますが）利用者がPCのセットアップ時に設定した「日本で利用」という情報をもとに、適切な日時に変換して表示しています。
このデータベースの更新は、一般に OS のアップデートに含まれて配布されます。
（一部の環境では個別に更新することもあります）
つまり、正しい対応としては、マイクロソフト等が夏時間の実施情報をOSの一部に組み込み、それを配布することになります。
サポート中のOSに関しては、この時間帯情報が配布されますので、普通にアップデートしていれば問題ありません。
夏時間の実施時刻になると勝手に反映されます。
XPやVista、古いAndroidなどサポートされていないOSに関しては、この情報は配布されないでしょう。
さて、サポートされていないOSをどうしても使いたい場合はどうしたらいいでしょうか。使わないというのはとりあえずなしで。
時計を2時間進めますか？
どうしても、そのような環境を使用したい場合は、協定世界時に対して11時間進んだ時間帯を使用しているところにいることにする のが妥当でしょう。
あるいは、人間が頑張って読み替える。
こうしないと、身近なところでは、USBメモリなどでやり取りしたときに2時間ずれて表示されるなどの問題が発生します。
その他、記録時間等が信頼できなくなるので、警察対応や裁判などで信頼性が問われる可能性もあります。
正しい対応のまとめです。
- ちゃんとサポート中のOSを使う
- ちゃんとOSを更新する
- ちゃんと更新されたOSでは、時計を変更する必要は全くない。むしろ変更してはダメ。
- どうしてもそのような環境を使えない場合は、UTC+11 のタイムゾーンにいることにして設定を変更する（時計を変更するのではなく、居る場所を変更する）。
NTP や GPS
NTPやGPSの時間でも勘違いしている人がいます。
※NTP: ネットワーク越しに「正しい」時間を受け取るための仕組み。
※GPS: ご存知、現在位置を測定するための仕組み。電波に「正確な日時」を含むため時刻同期に使用可能。
NTPやGPSの時刻情報は（数え始める基準日が違いますが）、「ある基準日時からの経過秒」を示します。
「ユニックス時間」の親戚だと思ってもらえればよく、（精度問題(=どこまで細かく表現できるか。1/1000秒なのか、1/1000000秒なのかという意味)を無視すれば）、相互に変換できます。
アメリカのNTPサーバに同期しても、あなたのPCの時計はアメリカ時間になったりしません。
このことからわかる通り、「表示のための日時」とは関係ありません。
コンピュータは受け取った時刻情報と、タイムゾーンの情報をもとに人間に対して提示します。
GPSは、そもそも「宇宙から電波を一方的に送り付けているだけ」ということから明らかですが、世界で共通のデータであり、タイムゾーン情報を含んでいるはずがありません。
日本に電波が届いたということは、1時間ずれている中国や台湾にも届いている可能性は高いですからね。
何より、国内の主要領土だけで4つのタイムゾーンをもっている米国の仕組みですから、そんなアホなことにはなっていません。
じゃあサマータイムに特に問題は発生しないの？
表示だけしかしないプログラムであれば、その可能性は高いでしょう。
昔の政府の調査で、「交通信号の対応にこれだけかかりますよ」みたいなのがあるみたいですが、あれは簡単な部類でしょう。
（切替タイミングでおかしくしなければ、タイムゾーン情報を持てればあとは「表示」だけなので）
例えば、勤怠管理、簡単に言うとタイムカードの処理を考えます。大体サマータイムの実施は深夜なので、深夜勤務ですね。
2019-06-02 1:59:59.999 の次を 2019-06-02 4:00:00.000 にする 2 時間のサマータイムを実施するとしましょう。
日本で作成されている一般的なプログラムでは、「2019-06-01 22:00:00 出勤、2019-06-02 06:00:00 退勤」などと記録します。
さて、今までであればこれを 6時(=30時) から 22 時を引いて、8 時間勤務 と計算できるわけです。
しかし、この勤務時間計算は間違っています。本当の勤務時間は 6 時間です。これによって、経営者は 2 時間分余計に給料を払わなければならなくなる可能性があります。
この場合でサマータイムの開始時はまだマシです。戻すことも考えてみましょう。
2019-10-06 3:59:59.999 の次を 2019-10-06 02:00:00.000 とする標準時への変更を考えます。（おかしな表記に見えますが、実際にこんな感じになります）
同様に、「2019-10-05 22:00:00 出勤、2019-10-06 06:00:00 退勤」と記録します。
これも8時間ではありません。10時間勤務が正しい計算となります。超過勤務ですね。うっかり 2 時間分もらい損ねないようにしないと。
業界によっては、「退勤から次の出勤までの間隔」を定めていて、それを下回る勤務はできないことになっているところもあるらしいです。
そのようなところでは、「ある日は夜の長さが2時間短く、別のある日は2時間長い」ということを考慮するようにしなければなりません。
一日の長さが24時間固定ではなくなるわけですから、現在のように、単純な数字の足し算引き算では対応できなくなるわけです。
このあたり、日本のプログラム全てがちゃんと対応できているとは思えません。
これに対する正しい対応方法は、『「協定世界時(UTC)」などで記録し、入出力するときにローカル時間（日本時間）との変換を行う』ような感じになります。
日本で稼働しているシステムで、現在このように処理しているシステムの数は……たぶん半分もないんじゃないですかね。
（コンピュータが普及する前にサマータイムを開始している欧州や米国は、最初からそのようにプログラムを書いているはずです）
また、よくある「日時を選ぶ」入力も問題になります。
上のサマータイム実施例で「2019-10-05 03:00:00」と入力された場合、さて、これは1回目の3時でしょうか、2回目の3時でしょうか。
この問題に関しては、多分、欧州や米国の人は「このあたりにルーズになる」ことで対応しているのだと思います。適当。
ほかにも、「システム連携で日本時間を送りあう。大幅にずれていればエラー」とするようなシステムがあって、どちらかが「夏時間には対応しない」などとすれば問題になります。
時間の計算や連携をしなくても、現在のコンピュータシステムでは「夜間にデータをまとめて処理する」ようなことが多々あります。これを「夜間バッチ」などといいます。
この「夜間バッチ」の終了が結構業務開始ギリギリになっている場合があります。
サマータイム開始時には一日の長さが22時間の日がある（夜が2時間短い）ことになりますから、この処理が間に合わない可能性があります。
これによって、銀行の業務などが停止し、ATMが使えないなどの障害が発生するかもしれません。
この夜間バッチに関しては、「間に合わない」だけではなくて、「いつ起動するか」も問題になります。
「毎日 2:30 にこの処理を実行してね」と書いている場合、（サマータイムの実施開始・終了日を無視すれば）毎日1回、ほぼ24時間ごとに実行されることになります。これは実際によくある処理です。
サマータイム開始日には「その時刻が存在しない」可能性、終了日には「その時刻が2回ある」可能性があります。どちらも大惨事を引き起こしかねません。
そのような場合にいつ、何回起動されるかは実装によって異なります。
「サマータイム対応」には「そのような場合にどうなるか」の確認も必要なわけですね。
元号や消費税率の変更のような「いつか起きるもの」については、あらかじめ仕組みを用意しておくのが合理的です。
特に改元はその性質上、「明日変わるかもしれない」ものですから必須とも言えます。
一方で、夏時間のように「やるかどうかも不明、やるとしてもどうやるのか不明」なものに関しては、準備しておくのが必ずしも合理的とは言えません。
変わることがわかっているものは「ここを変える」と印をつけているか、最初から変えやすいようにしておくのが一般的です。
一方で、「夏時間は存在しない」という前提のもとで長年作られている日本のシステムは、「どこを変更したらいいか」もわからないようになっています。
影響があるかどうかを調査するだけで膨大なコストになるでしょう。