新聞を読んだ後、私は2035年頃に私たちの地球上の人々とコンピュータがどうするべきかを自分に尋ねました。時間を1秒後に設定します天文学的な時間に合わせて。
この記事を読んだとき、私は初めてこれがコンピュータに多くの問題を引き起こすと信じていました。戻って既に存在する秒を再生できる時計は、オペレーティングシステムをはじめ多くのプログラムではサポートされません。
しかし、私たちは毎年同様のことをしていることを発見しました。つまり、冬時間を適用するときは、1時間後に戻ります。すべての国が同じかどうかはわかりませんが、夜明けの3時になると、私たちは2時に決めました。
2024-10-27 02:59:59.999999この時間が変更され、タイムスタンプがからに変わると、Linuxオペレーティングシステムはタイムスタンプ付きタスクをどのように管理しますか2024-10-27 02:00:00.000000？たとえば、時間ごとにソートされたすべてのメッセージはなりすまします。
システムタイムスタンプに関する限り、from to（+1）（秒単位）は続行されて2024-10-27 02:59:59.999999いますか？2024-10-27 02:00:00.00000017300699991730070000
この場合、2035年には私たちの時間を1秒短縮する問題と、毎年しているように1時間後に移動する問題は違うのだろうか？たとえば、次のように割り当てることができ
2019682799 = 2034-12-31 23:59.59ます
2019682800 = 2035-01-01 00:00.00。
2019682801 = 2035-01-01 00:00.00
2019682802 = 2035-01-01 00:00.01
しかし、ここで問題は次のとおりです。
正しいオペレーティングシステムを使用しているコンピュータは、変更されていないコンピュータ（古いまたは更新されていないオペレーティングシステム）に遭遇します。
2019682801 = 2035-01-01 00:00.01しかし、2019682802 = 2035-01-01 00:00.02これは本当ではありません。しかし、一部のオペレーティングシステムがまだ存在し、夏時間や冬時間の変更がわからない場合でも、同じ問題が発生します。世界にこのようなコード例はあまりないと思います。
timestamp = System.timeInMillis() millis = millis % 1000 secondsSince1970 = millis / 1000 seconds = secondsSince1970 % 60 minutesSince1970 = ...なぜならここで
seconds二次削除を適用すると、2035年には変数が間違ってしまうからで2019682802はない。0102
ベストアンサー1
Linuxでは、オペレーティングシステムはデフォルトで夏時間の変更なしにUTC時間で動作する時計を維持します。
（通常）夏時間は1時間で指定されます。時計は変更しませんが、表示時に現地時間に適用されるUTCオフセットを変更します。。
たとえば、中央ヨーロッパのタイムゾーンでは、タイムスタンプ
2024-10-27 02:59:59.999999 UTC+2 = 2024-10-27 00:59:59.999999 UTC = 1730001599
その後にタイムスタンプが表示されます。
2024-10-27 02:00:00.000000 UTC+1 = 2024-10-27 01:00:00.000000 UTC = 1730001600
（ここではPOSIXタイムゾーン指定子を使用しないことに注意してください。POSIX仕様の基盤となるシステムは主にアメリカで開発されており、独自に正の整数タイムゾーン指定子を予約しているため、POSIXタイムゾーンオフセットの符号は次のとおりです。考えるのとは異なる反対の期待は、UTCオフセットの一般的な理解に基づいています。
そのため、プログラムがタイムスタンプを現地時間形式で保存する必要がある場合常にUTCオフセット識別子を含める必要があります。タイムスタンプで。プログラムが夏時間の終わりに人間のレベルのあいまいさを防ぐ必要がある場合は、常にUTCに対応する形式で内部的にタイムスタンプを保存する必要があります。
「UTC時間を1秒後に移動」は、時間スケールに1秒を追加するのと同じです。これは新しいことではありません。、UTCタイムスタンダードにはすでにこれを行う標準的な方法があります。ユンチョ。毎年6月末と12月末（UTC）にうるう秒を挿入する機会があります。
xxxx-12-31 23:59:59 UTC
次は
xxxx-12-31 23:59:60 UTC
その後
(xxxx+1)-01-01 00:00:00 UTC
これが実際に起こるかどうかは、国際機関IERSが決定した地球自転の測定可能な欠陥に依存します。
うるう秒が最後に挿入された時は2016年末でした。
https://hpiers.obspm.fr/eoppc/bul/bulc/UTC-TAI.history
現時点では、2024年6月末にうるう秒を挿入する予定はありません。うるう秒の挿入の次の権威のあるソースはIERS Bulletin Cです。
https://datacenter.iers.org/data/latestVersion/bulletinC.txt
NTP時間同期プロトコルには、この問題を解決するためのうるう秒通知機能があります。 Linuxdateコマンドは、オペレーティングシステムが何が起こっているのかを知っていることを証明するために、適切な時間に23:59:60 UTCタイムスタンプを誠実に表示します。しかし、明らかに、これはすべてのUnixタイムスタンプ秒の長さが同じではないことを意味します。うるう秒が挿入される前に、ほとんどのオペレーティングシステムはUnixタイム秒を2秒の長さと見なします。
（NTPには「負のうるう秒」機能もありますが、これまでは実際に要求されたことがなく、近い将来にも要求されないと予想されます。）
新しい代替実用的なソリューションは次のとおりです。ジャンプスミア：追加の1秒はシステムクロックの速度を遅くして処理されるため、追加の1秒が1日程度かかります。これは、1秒あたりの長さの均一性が+/- 1秒の範囲のタイムスタンプの絶対精度よりも重要であるという考えに基づいています。おそらく、ほとんどの「一般目的」時間目的に有効な解決策でしょう。
うるう秒は、常に1秒未満のタイミング精度または半年以上のすべての時間範囲で正確な秒数を計算する必要がある人にとって問題になります。しかし、これらの正確さを必要とするほとんどの人はすでにこの事実を認識し対処していることがわかりました。
Linux / Unixシステムでこれらの高精度タイミングが必要な場合は、UTCの代わりに国際原子時間（TAI）を展開するためにローカル時刻同期機能（変更されたNTPサーバーなど）を設定できます。その後、システムクロックをUTCの代わりにTAIとして実行し、right/IANA / Olsonタイムゾーンデータベースのタイムゾーンバリアントを使用できます（つまりright/Europe/Paris、Europe/Parisうるう秒を含みます）。