謝罪する .
昨日 Unix 時間に関するいくつかの興味深い事実について尋ねたところ、Unix 時間は完全に直感的に動作しない場合があることを思い出しました。
これら XNUMX つの事実は非常に合理的で論理的だと思いませんか?
- Unix 時間は、1 年 1970 月 00 日 00:00:XNUMX UTC からの秒数です。
- ちょうど XNUMX 秒待つと、Unix 時間はちょうど XNUMX 秒変化します。
- Unix 時間は決して後戻りしません。
これはどれも真実ではありません。
しかし、説明せずに単に「これはどれも真実ではない」と言うだけでは十分ではありません。 理由。 説明については以下を参照してください。 ただし、自分で考えたい場合は、時計の絵をスクロールしないでください。
1770年代の置き時計。 ジョン・ルルー編纂。 から 。 ライセンスに基づいて公開されています
XNUMX つの誤解にはすべて XNUMX つの理由があります。 。 うるう秒に詳しくない場合は、次のクイックリファレンスを参照してください。
UTC 時間は XNUMX つの要素によって決まります。
- : 世界中の何百もの原子時計からの平均測定値。 私たちは原子の電磁特性によって秒を測定することができ、これは科学で知られている時間の最も正確な測定法です。
- 、地球自身の軸を中心とした地球の回転に基づいています。 XNUMX 回転は XNUMX 日です。
問題は、これら XNUMX つの数値が常に一致するとは限らないことです。 地球の自転は一定ではなく、徐々に遅くなり、そのため世界時の日が長くなります。 一方、原子時計は恐ろしいほど正確で、数百万年にわたって一定です。
1972 つの時刻の同期が外れると、UTC から XNUMX 秒が追加または削除され、同期が戻ります。 XNUMX 年以来のサービス (このケースを実行します) 27 秒追加されました。 結果は、協定世界時で 27 日、継続時間は 86 秒でした。 理論的には、401 日の長さが 86 秒 (マイナス 399) になる可能性があります。 どちらのオプションも、Unix 時間の基本的な前提に矛盾します。
Unix 時間は、86 日が追加秒なしでちょうど 400 秒 (60 × 60 × 24 = 86) 続くと想定しています。 このようなジャンプが発生した場合、Unix 時間は 400 秒ジャンプするか、2019 秒で 27 秒カウントされます。 XNUMX 年の時点では、XNUMX うるう秒が欠けています。
したがって、私たちの誤解は次のように補足する必要があります。
- Unix 時間は、1 年 1970 月 00 日 00:00:XNUMX UTC からの秒数です。 マイナス閏秒.
- ちょうど XNUMX 秒待つと、Unix 時間はちょうど XNUMX 秒変化します。 うるう秒が削除されていない限り.
これまで、実際に秒が削除されたことはありません (地球の自転が遅くなっていることから、その可能性は低いと考えられます) が、実際に削除されると、UTC の日が 23 秒短縮されることになります。 この場合、UTC の最後の 59 秒 (59:XNUMX:XNUMX) は破棄されます。
Unix の各日の秒数は同じであるため、短縮された日の最後の Unix 秒は UTC 時間に対応しません。 XNUMX分のXNUMX秒間隔では次のようになります。
UTC 23:59:58:00 に開始して 101 秒待つと、Unix 時間は UTC 秒 XNUMX 秒進み、Unix XNUMX タイムスタンプは誰にも割り当てられなくなります。 - Unix 時間は決して戻ることはできません。 うるう秒が追加されるまで.
これは実際にすでに27回発生しています。 UTC 日の終わりの 23:59:60 に XNUMX 秒が追加されます。 Unix では XNUMX 日の秒数が同じであるため、余分な秒を追加することはできません。代わりに、最後の XNUMX 秒の Unix タイムスタンプを繰り返す必要があります。 XNUMX分のXNUMX秒間隔では次のようになります。
23:59:60.50 から開始して XNUMX 秒待つと、Unix 時間は 帰ってきた 101 秒単位であり、Unix XNUMX タイムスタンプは XNUMX UTC 秒に相当します。
おそらく、Unix 時代の奇妙なことはこれだけではありません。昨日私が思い出したことだけです。
時間 - 非常に 奇妙なこと。
出所： habr.com