最近、サマータイムを導入するべきかどうかの議論が盛んですが、どうも、一般的なコンピュータ（Windows や Linux）の文脈で「時計を合わせる」という考え方があるようです。
端的に答えだけ言うと、一般的なコンピュータにおいて 時計を進めたり戻したりすることはありません し、するものでもありません。
なお、きわめて単純なマイコン（例えば電子レンジやエアコン、炊飯器の時間など）はこの限りではありません。
コンピュータの日時管理
現代の一般的な PC において、ある時点を起点として、サマータイムの実施の有無にかかわらず、一定の間隔で数え続けるのが普通です。
といっても、普通の人には意味がわからないと思います。
現在、一般的に使われているOSでは、（日本時間の）1970年1月1日 午前9時ちょうどからの経過時間を秒単位で保持し、加算しています。
その時間からずっと止まらないストップウォッチだと思ってもらえば良いでしょう。
（閏秒は扱いがめんどくさいのでここでは完全に無視します）
0秒
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━→ ずっと未来までつづく
1970/1/1 9:00 ↑現在
じゃあ、今が何秒なのかというと、このくらいです→「ここに表示」
※青い画面で表示されていて、「ここに表示」のままになっている場合は、ここをタップ（あるいはクリック）してください。
この数字は、「ユニックス時間 (UNIX時間)」などと呼ばれていて、世界で共通の値です。
「世界で共通」というのはどういう意味でしょうか。
「今、この瞬間」、日本では「ある時刻」ですが、例えばアメリカでは「別のある時刻」です。
「ある時刻」といってもわかりづらいので、具体的にしましょう。
- 日本（標準時）: 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
これらは、同じ瞬間です。
※細かいことを言うと、いろいろありますが、そういうことにしておいてください。実用的にはそれで充分です。
※「協定世界時」は耳慣れない言葉ですが、「グリニッジ標準時と大体同じ」です。歴史的な経緯から、英国のグリニッジ天文台（の近く）を通る子午線をつくり、それを0°として、その地方時を基準としています。
余談ですが、英国は夏時間を導入しているので、英国の時間と協定世界時は違います。（日本との時差は9時間ですが、夏期には8時間になります）
コンピュータの中の処理で考えると、「現在のユニックス時間」＋「タイムゾーン情報」（後述）を使って、「あなたの生活している時間」を表示します。
さて、誰かが何かをした――たとえば、今あなたがツイートした、あるいは何か商品を購入した――時間というのは、今あなたが生活している時間にかかわらず同じ瞬間のはずです。
現在、中央欧州夏時間と日本時間の差は（上述の通り）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
これは世界の時刻との整合性が取れなくなってしまっています。あいつら、未来に生きてんなというやつです。あなたのPCだけ世界から2時間進んでしまっています。
正しい対応の方法
普通のOS（雑な言い方）では、「この地域では、協定世界時に対して何時間ずれた時刻で生活をしている」という情報を持っています。
これを一般に「タイムゾーン情報」とか「時間帯情報」とかいいます。「tzdata」とかもいいます。まあ、何でもいいです。
雑に言うと、「協定世界時との時差」の情報を全世界分持っています。
また、すでに夏時間が導入されている国や地域などでは、「いつからいつまで夏時間」という情報も同時に持っています。
過去に実施されていた「日本の夏時間」にも対応したデータがあります。
夏時間以外にも、「標準時の変更」の情報もこれに含まれています。
例えば、北朝鮮の標準時が +9:00 から +8:30 になって +9:00 に戻った情報も記録されており、（仮に北朝鮮の時刻で表示しようとすれば）正しく反映されます。
コンピュータは、このデータベースと、（たぶん記憶にないと思いますが）利用者がPCのセットアップ時に設定した「日本で利用」（設定上は「東京、大阪、札幌」や「Asia/Tokyo」）という情報をもとに、適切な日時に変換して表示しています。
このデータベースの更新は、一般に OS のアップデートに含まれて配布されます。
（一部の環境では個別に更新することもあります）
つまり、正しい対応としては、マイクロソフト等が夏時間の実施情報をOSの一部に組み込み、それを配布することになります。
サポート中のOSに関しては、この時間帯情報が配布されますので、普通にアップデートしていれば問題ありません。
夏時間の実施時刻になると勝手に反映されます。
XPやVista、古いAndroidなどサポートされていないOSに関しては、この情報は配布されないでしょう。
さて、サポートされていないOSをどうしても使いたい場合はどうしたらいいでしょうか。使わないというのはとりあえずなしで。
時計を2時間進めますか？
どうしても、そのような環境を使用したい場合は、協定世界時に対して11時間進んだ時間帯を使用しているところに居ることにする のが妥当でしょう。
あるいは、人間が頑張って読み替える。
こうしないと、身近なところでは、USBメモリなどでやり取りしたときに2時間ずれて表示されるなどの問題が発生するかもしれません（NTFSフォーマットの場合）。
その他、記録時間等が信頼できなくなるので、警察対応や裁判などで信頼性が問われる可能性もあります。
正しい対応のまとめです。
- ちゃんとサポート中のOSを使う
- ちゃんとOSを更新する
- ちゃんと更新されたOSでは、時計を変更する必要は全くない。むしろ変更してはダメ。
- どうしてもそのような環境を使えない場合は、UTC+11 のタイムゾーンにいることにして設定を変更する（時計を変更するのではなく、居る場所を変更する）。
Windows や Mac、iOS (iPhone/iPad) についてはサポート中なら大丈夫と言える（Appleはサポート期限明示してないのはおいておく）けど、Android どうするんだろう…。
ただでさえ Android のアップデートろくに降ってこないのにサポート対応できるのかな…。
NTP や GPS
NTPやGPSの時間でも勘違いしている人がいます。
※NTP: ネットワーク越しに「正しい」時間を受け取るための仕組み。
※GPS: ご存知、現在位置を測定するための仕組み。電波に「正確な日時」を含むため時刻同期に使用可能。
NTPやGPSの時刻情報は（数え始める基準日と精度が違いますが）、「ある基準日時からの経過時間」を示します。
「ユニックス時間」の親戚だと思ってもらえればよく、（精度問題(=どこまで細かく表現できるか。1/1000秒なのか、1/1000000秒なのかという意味)を無視すれば）、相互に変換できます。
アメリカのNTPサーバに同期しても、あなたのPCの時計はアメリカ時間になったりしません。
たぶん、今のWindowsを普通にインストールすると、自動的に「time.windows.com」というNTPサーバと同期するように設定されていると思います。
このtime.windows.comはたぶんアメリカにあると思いますが、世界中のどこにあったとしても、期待通りに動作します。
NTPサーバが「基準時刻」を送信する→PCが「基準時刻」を「ユニックス時間（等の内部時間）に変換する」→表示するときに、タイムゾーン情報を参照して人間が読める日時に変換する、という流れです。
このことからわかる通り、「表示のための日時」とは関係ありません。
コンピュータは受け取った時刻情報と、タイムゾーンの情報をもとに人間に対して提示します。
GPSは、そもそも「宇宙から電波を一方的に送り付けているだけ」ということから明らかですが、世界で共通のデータであり、タイムゾーン情報を含んでいるはずがありません。
（ロシアの「グロナス」というGPSに似た衛星システムは、常にモスクワ時間を送信していますが、これも「UTCに対して3時間の時差を含んでいる」ことを除けば同じです）
日本に電波が届いたということは、1時間ずれている中国や台湾にも届いている可能性は高いですからね。
何より、国内の主要領土だけで4つのタイムゾーンをもっていてその境界は極めて人為的な米国の仕組みですから、そんなアホなことにはなっていません。
（GPSの信号は、自分の居場所と正確な時間を送り続けるだけです。この信号を複数受信して方程式を解くと、緯度・経度・高度・時間がわかります）
（とは言え、前述のグロナスはタイムゾーンがたくさんあるロシアの仕組みで、その全土（というか全球）でモスクワ時間を受信するわけですが…）
※厳密にいうと、UTCと各国のローカル時間は厳密に同期しているとは限りませんが、ここでは無視できるものとします。
GPSはタイムゾーン情報を含んでいないということは、身近なところでは何が起きるでしょうか。
おそらく、カーナビはGPSから時間をもらっていると思いますが、これを正しい日本時間で表示するためには、タイムゾーンデータベースの更新が必要です。
果たしてカーナビのタイムゾーンDBのアップデートは来るでしょうか。（まあ、来ないですよね、その時点での最新機種以外は）
そもそも、日本製カーナビ、途中でタイムゾーンが変化する可能性とか考慮してるのかな…。
まあカーナビくらいなら時間がずれていても、大したことにはなりません。
カーナビには詳しくないのですが、時間帯によって規制（車両通行禁止など）や料金変更（高速道路とか）を考慮するような機種が存在するのなら、そのあたりには影響するかもしれません。
まあ、普通はこの程度では「人は死なない」ので、大した問題ではないです。
じゃあサマータイムに特に問題は発生しないの？
本当に表示だけしかしないプログラムであれば（←ここ大変重要）、その可能性は高いでしょう。
昔の政府の調査で、「交通信号の対応にこれだけかかりますよ」みたいなのがあるみたいですが、あれは簡単な部類だと考えられます。
（切替タイミングでおかしくしなければ、タイムゾーン情報を持てればあとは「表示」だけなので。ものすごく変なプログラムを組んでいたら、夏時間から戻る時に2時間以上赤になりっぱなしとか面白いことは起こせるかもしれません。）
例えば、勤怠管理、簡単に言うとタイムカードの処理を考えます。大体サマータイムの実施は深夜なので、深夜勤務ですね。
仮に、（よく使われる2時とか3時の切り替えに準ずると仮定して）2019-06-02 1:59:59.999 の次（0.001 秒後）を 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 時間分もらい損ねないようにしないと。
業界によっては、「退勤から次の出勤までの間隔」を定めていて、それを下回る勤務はできないことになっているところもあるらしいです。
（たとえば、退勤から出勤まで8時間以上必要など。夏時間突入を考えずに計算すると、6時間でスケジュールを組んでしまいかねません）
そのようなところでは、「ある日は夜の長さが2時間短く、別のある日は2時間長い」ということを考慮するようにしなければなりません。
医療や農業で、「4 時間ごとに『処理 A』を行う必要がある」ようなものも想定できます。
「処理 A」は何らかの薬剤の投与だったり、水まきだったりするでしょう。医療関係者でも農業関係者でもないので知りませんけど。
今、午前0時ちょうどに処理を行ったとします。次の処理は午前4時ちょうどです。
さて、この状態（「午前4時に処理をする」と予約している状態）で、午前2時からサマータイムが開始されたらどうなるでしょうか。
時計は午前2時になろうとした瞬間に、午前4時になります。
そのシステムは、午前4時になったので「処理 A」を行います。
さて、この「処理 A」の間隔はどうなったでしょうか。
「午前0時」の次に「午前4時」の処理を行っていますが、間は2時間です。
水やり程度ならまあ大した影響はないと思いますが、薬剤の投与だったりすると過剰投与になって大惨事ですかね。
サマータイム終了時にも、「午前4時になった（なろうとした）瞬間に午前2時に戻る」ということが起きるので、同じようなことが発生しかねません。
まあ医療関係の器具がそんな作りになっているとは思えませんが、サマータイム導入前に、そんな作りになっていないことを確認する必要があります。
サマータイムを導入すると、一日の長さが24時間固定ではなくなるわけですから、現在のように、単純な数字の足し算引き算では対応できなくなるわけです。
このあたり、日本のプログラム全てがちゃんと対応できているとは思えません。
※2時間のサマータイムを導入すると、「22時間の日が1日、26時間の日が1日、24時間の日が363日か364日」になります。
これに対する正しい対応方法は、『「協定世界時(UTC)」などで記録し、入出力するときにローカル時間（日本時間）との変換を行う』ような感じになります。
日本で稼働しているシステムで、現在このように処理しているシステムの数は……たぶん半分もないんじゃないですかね。
（コンピュータが普及する前にサマータイムを開始している欧州や米国は、最初からそのようにプログラムを書いているはずです。まあ現実にはそうでもなくていろいろアレなんですが…）
単に「協定世界時で処理をして、きちんと計算すればいい」とも言い切れません。
日本人は一日の長さが変動するなんて夢にも思っていませんから、当たり前のように「24時間後に」とか「1日後に」とか仕様を決めます。2日や7日でも同じです。
果たしてその仕様とされた「24時間」というのは本当に24時間でいいのでしょうか。「1日」のつもりで書かれたものではないでしょうか。
サマータイムを導入すると、1日と24時間は等しくなくなります。
例えば「24時間乾燥させる」のような要件の場合は、本当に24時間で処理するのが妥当なのでしょう。
一方で、「24時間以内に連絡」のような場合は、単に「1日後」のつもりで書かれている可能性があるので、1日後の同時刻とするのが正しいかもしれません。
これは、システムや文脈によって個別に判断しなければなりません。これはとても大変なことです。
仮に「1日後の同時刻」を求められている場合、 協定世界時では1日は24時間（うるう秒の関係で1秒増えたり減ったりする可能性はありますが）ですから、「1日後の同時刻」を計算するためには、一回日本のローカル時間に変換したり、夏時間のルールを参照したりしないといけません。
ですから、単に「協定世界時で処理してるから表示だけの問題だもーん」ともなりません。
また、よくある「日時を選ぶ」入力も問題になります。
上のサマータイム実施例で「2019-10-05 03:00:00」と入力された場合、さて、これは1回目の3時でしょうか、2回目の3時でしょうか。
この問題に関しては、多分、欧州や米国の人は「このあたりにルーズになる」ことで対応しているのだと思います。適当。
「表示されている時間がどの時間帯なのかわからない問題」に関しては、ログ（記録）の問題もあります。
コンピュータシステムでは、ある時間に何かが起きましたよ、こういうことをしましたよ、ここまで完了しましたよという記録に、発生日時の情報を添えることで時系列をわかりやすくすることがよくあります。というか記録しないと大した役に立たないことが多いです。
例えば、このブログをあなたが読んだとき、サーバのログには「このIPアドレスから、この時間に、こんな要求がありましたよ」というデータが記録されます。
「発生日時」を記録する、しかもそれは人間が読むためのものであるということは、ここにタイムゾーンの問題が出てきます。
現在、日本で開発された、日本専用のシステムではこのような場合、単に「YYYY/MM/DD HH:MM:SS」みたいな形式で吐かれていることが多いと思われます。もちろん日本標準時で。
ここで、サマータイムが導入され、システムが自動的に対応したとすると、このタイムスタンプはどっちの時間帯なのかわかりません。（もちろん、曖昧でない時間については問題ないですが）
そこで、考えられる対応としては次のものがあります。
- 常に日本標準時で出力する ―― ここの部分だけ「常に日本標準時で出力する」ための専用の処理を追加しなければならないかもしれません。
- 何も考えずにそのまま ―― どちらの時間帯なのかわかりません。充分にログが出力されていれば流れとかでわかるかもしれませんが。
- タイムゾーンをUTCに変更する ―― 途中から変更するのは正直かなり厳しいでしょう。最初からそうなっていればともかく。あとは読む人間に負荷がかかります。9時間とか11時間とか足し算引き算したいですか？
- タイムゾーンを記録する ―― これがまあ妥当な対応になるでしょう。しかし、例えばこのログを解析するシステムが別にある場合（最近はすっかり廃れましたが、ウェブサーバのログを解析してアクセス解析するとか普通にありました）その部分がフォーマットを解釈できずに死ぬかもしれません。
どれを選んでも大変しんどいですね。問題ないことの確認とかが。
ちなみに、世の中で実際に広く使われているプログラムでは、プログラム起動時のタイムゾーンで記録し続けるそうです。それはどうなんだ…。
ほかにも、「システム連携で日本時間を送りあう。大幅にずれていればエラー」とするようなシステムがあって、どちらかが「夏時間には対応しない」などとすれば問題になります。
時間の計算や連携をしなくても、現在のコンピュータシステムでは「夜間にデータをまとめて処理する」ようなことが多々あります。これを「夜間バッチ」などといいます。
この「夜間バッチ」の終了が結構業務開始ギリギリになっている場合があります。
サマータイム開始時には一日の長さが22時間の日がある（夜が2時間短い）ことになりますから、この処理が間に合わない可能性があります。
これによって、銀行の業務などが停止し、ATMが使えないなどの障害が発生するかもしれません。
この夜間バッチに関しては、「間に合わない」だけではなくて、「いつ起動するか」も問題になります。
「毎日 2:30 にこの処理を実行してね」と書いている場合、（サマータイムの実施開始・終了日を無視すれば）毎日1回、ほぼ24時間ごとに実行されることになります。これは実際によくある処理です。
サマータイム開始日には「その時刻が存在しない」可能性、終了日には「その時刻が2回ある」可能性があります。どちらも大惨事を引き起こしかねません。
そのような場合にいつ、何回起動されるかは実装によって異なります。
「サマータイム対応」には「そのような場合にどうなるか」の確認も必要なわけですね。
元号や消費税率の変更のような「近い将来確実に、あるいは、きっと起きるもの」については、あらかじめ仕組みを用意しておくのが合理的です。
特に改元はその性質上、「明日変わるかもしれない」ものですから必須とも言えます。
一方で、夏時間のように「やるかどうかも不明、やるとしてもどうやるのか不明」なものに関しては、準備しておくのが必ずしも合理的とは言えません。
変わることがわかっているものは「ここを変える」と印をつけているか、最初から変えやすいようにしておくのが一般的です。
一方で、「夏時間は存在しない」という前提のもとで長年作られている日本のシステムは、「どこを変更したらいいか」もわからないようになっています。
影響があるかどうかを調査するだけで膨大なコストになるでしょう。
そもそも、大半の日本のプログラマは「夏時間を考慮する」というのが何が必要なのか理解できていないと思われます。そこの勉強からやらないといけないわけです。
まずですね、こんな解説の記事が必要になってる時点で夏時間に対する理解が足りているとは到底言えないわけです。
よく言われていること
二時間のサマータイムは前例がないのでOS等の対応が行われていない
嘘と言っていいです。OS等には「サマータイムは1時間である」と仮定したコードは無いと考えて良いです。
世の中には30分のサマータイムを実施している地域も存在しますし、過去にはイギリスで「二重夏時間」を導入し、2時間ずれていたこともあります。
また、夏時間とは関係のない「標準時」の変更も同様の仕組みで行いますから、たぶん秒単位で扱えるはずです。
ただし、標準電波（電波時計用によく使われる。JJY）のフォーマットが 1 時間しか考慮していない 話のように、「アプリケーションレベル」と言われる単位では、1時間と想定している可能性もあります。
また、サマータイムに慣れているアメリカ人がやらかしたプログラムの例がここにあります。（夏時間実施中フラグを確認したらｴｲﾔｯと60分補正するコード。現状では60分以外はレアケースなので彼を責める意図は全くありません）
既存の広く使われているプログラムでも、2時間のサマータイムでは何か起きる可能性がないとは言い切れない、かもしれません。
「Asia/Tokyo」は「JST = 日本標準時」を示し、サマータイムとは関係がない
ちょっと何を言っているかよくわからないです。
Asia/Tokyo タイムゾーンは、”東京で使われている・使われていた・使われるであろう” タイムゾーンの情報であり、当然に夏時間の情報も含みます。
Europe/Paris タイムゾーンとか少し試してみればわかりますが、シームレスに切り替わります。
自分のところは夏時間に関することはスルーする（夏時間を適用しない）ので、何もしなくて問題ない
OSを更新した時にタイムゾーンデータベースが勝手に更新されないように措置すれば、そうですね。
その場合の法的整合性とかについては知りませんけど。
また、未来の保守において、その部分が足を引っ張る可能性がありますから充分に注意してください。
（未来のOSを導入すれば、当然その日時には夏時間が適用されるというデータを持っていますよね）
コンピュータの時間は変わらないことになりますが、きっと周りの時間は2時間進むので、それはそれで茨の道になる可能性があります。
安易に判断しないほうが良いですよ。
- バッチ突き抜け問題
- ログとかが2時間ずれる
じゃあ「韓国時間（Asia/Seoul）」とかにしておけばいい？
韓国では何度か夏時間の実施の実績がありますから、1988年以前のデータを扱う可能性があるならやめておいた方が無難です。
また、日本の時刻に関する法律から逃れる代わりに、韓国のそれに影響されるようになりますから、韓国で夏時間が施行されないか充分に注意をしてください。
まあ、デメリットしかない今の時代に夏時間を導入とか、まともであればしないと思いますけど。
あ、韓国は「+9:00はE135°子午線通ってないし、日本の支配の残滓でもあるから標準時を+8:30に変えよう」という運動がずっとくすぶってるようですから、それにも注意してください。
これも、今のところはデメリット大きすぎるからダメだ、と、まともな判断がされているようですが。
なお、周りの時間がずれることによるデメリットは上の「何もしない」と同じです。
どうしてもやりたいなら、 Etc/UTC-9 を参照するほうが良いと思います。このタイムゾーン非推奨ですけど。
一部の業務システムでデータを失う可能性があるってどういうこと？
この記事は、「コンピュータの中の時計は好き勝手にいじるものじゃないよ」という内容なので、完全に別の話ではあるのですが、一応。はてブコメントもついてるし。
この辺は実装に強く依存するので一概には言えないのですが、設計によっては（そのままだと）データを一部失う可能性があります。
例えば、24時間受付で、何かを受注するシステムを考えます。（オンラインショッピングとかが当てはまりますね）
その受注システムは、一時間に一回、YYYYMMDDHH.dat というファイル名で受注データを作成して、一日数回、合計24ファイルを別のシステムに引き渡すとします。
（YYYYMMDD = 年月日、HH=00～23時）
実際のシステムでは、こういう何かをまとめたデータだったり、ログデータだったりします。
まあ「ありそうな処理」です。
さて、夏時間が終了する日の事を考えましょう。
ここでは、上でも例に使った、「2019-10-06 3:59:59.999 の次を 2019-10-06 02:00:00.000 とする」移行とします。
上の仕様だと、0分になった直後にそういう処理をするプログラムを起動すればいいですかね。こんな感じで。
※(夏) は夏時間、(冬) は日本標準時を指します。
- 2019年10月6日 00:00(夏) 頃 :
2019100523.datを作成 - 2019年10月6日 01:00(夏) 頃 :
2019100600.datを作成 - 2019年10月6日 02:00(夏) 頃 :
2019100601.datを作成 - 2019年10月6日 03:00(夏) 頃 :
2019100602.datを作成 - 2019年10月6日 02:00(冬) 頃 :
2019100601.datを作成（！）（あるいは2019100603.datを作成） - 2019年10月6日 03:00(冬) 頃 :
2019100602.datを作成（！） - 2019年10月6日 04:00(冬) 頃 :
2019100603.datを作成
さて、お気づきの通り、ファイル名が重複してしまいました。
重複した時は何が起きるでしょうか。これはもちろん実装によりますが、
- ファイルが存在するのでエラーになる
- ファイルが存在するので上書きする
- ファイルに追記する
まあどれかになるでしょう。どれもありそうです。最後のはめんどくさいですからあんまりなさそうな気はします。
エラーになるとそれはそれで惨事ですが、上書きされたらもう大惨事です。
一部のデータを失ってしまいます。
「一部のデータを失う可能性がある」というのはこういうことです。
同様のケースで、1時間なり2時間に一回バックアップを取得している場合で、同様のファイル名をつけていたりすると、同じようなことが起きます。
この問題を修正するには、「この部分だけ常に冬時間で処理する」とか「この部分の仕様を変更する」とかしないといけません。
仕様の変更ができるのか、冬時間で処理しても問題ないのか、そういった確認も行う必要があるわけです。
また、このようなファイル名をつけている場合にさらに問題になるところがあります。
（必ずしも）ファイル名が時系列に並ばないのです。
このようなファイル名をつけている場合、「ファイル名で並び替えると時系列になる」と想定している可能性はそれなりにあります。
みなさんもきっと、日付をファイル名につけておいて、並び替えて時系列にしたことの一度や二度、あると思います。私はあります。たくさん。
日本時間にサマータイムが存在しないなら、そのような想定もそれなりに合理的であるわけで、「このような想定を行っていないことを保証せよ」と急に迫られても大変困るわけです。
実際はまあそんなオンラインシステムはそうそうないと思いますが（一日一回程度なら実際に見たことある）、例えばウェブカメラの画像を数秒ごとに保存する、その時のファイル名は日時とかはそこそこありそうですね。