Unix (POSIX) 時間に関して、ウィキペディアは次のように述べています。
うるう秒を処理するため、時間の線形表現でも UTC の真の表現でもありません。
しかし、Unixdateコマンドは実際にはそれらを認識していないようです。
$ date -d '@867715199' --utc
Mon Jun 30 23:59:59 UTC 1997
$ date -d '@867715200' --utc
Tue Jul 1 00:00:00 UTC 1997
にうるう秒があるはずですがMon Jun 30 23:59:60 UTC 1997。
これは、コマンドだけがdate閏秒を無視し、Unix 時間の概念は無視しないということですか?
1 日あたりの秒数は、Unix タイムスタンプで固定されています。
Unix 時間数は Unix エポックではゼロであり、エポックから 1 日あたり正確に 86400 ずつ増加します。
したがって、うるう秒を表すことはできません。OS はこれに対応するためにクロックを遅くします。Unix タイムスタンプに関する限り、うるう秒は存在しません。
Unix 時間は簡単に操作できますが、一部のタイムスタンプはリアルタイムではなく、一部のタイムスタンプは一意の時間ではありません。
つまり、2 つの異なる秒を表す重複したタイムスタンプがいくつかあります。これは、UNIX 時間では 60 秒が繰り返される可能性があるためです (61 秒はあり得ないため)。理論的には、60 秒が存在する必要がないため、将来のギャップになる可能性もありますが、これまでのところ、閏秒のスキップは発行されていません。
UNIX 時間の根拠: 簡単に操作できるように定義されています。標準ライブラリにうるう秒のサポートを追加するのは非常に難しい作業です。たとえば、データベースで 2050 年 1 月 1 日を表すとします。その日付が UTC で何秒先なのか、地球上の誰も知りません。日付を UTC タイムスタンプとして保存することはできません。これは、IAU が次の 10 年間に追加する必要がある閏秒の数がわからないためです (それらはランダムと同じくらい優れています)。では、将来の任意の 2 つの日付の間に経過する時間の長さが 1 年か 2 年前までわからない場合、プログラマーはどのように日付計算を行うことができるでしょうか? Unix 時間は単純です。2050 年 1 月 1 日のタイムスタンプはすでにわかっています (つまり、80 年 * 1 年の秒数)。UTC は 1 年中作業するのが非常に難しく、
なんといっても、うるう秒に同意するプログラマーに会ったことがありません。それらは明らかに廃止されるべきです。