問題タブ [leap-second]

Microsoft のドキュメントによると、このFILETIME構造は 1601 年 1 月 1 日 (おそらくその日の始まり) からカウントされますが、これにはうるう秒が含まれますか?

今週末は、6 月 30 日の後に追加の秒が挿入されるため、非常に長い週末になります。23:59:59

24 時間体制で大量のデータをログに記録するシステムがあり、ビジネス ルールの 1 つは、1 秒以内に 2 つのレコードが同時に発生したとしてログに記録できないことです。

新しいデータ型とともに UTC 日時を使用していますdatetimeoffsetが、私が知る限り、1 分間に 60 秒を超えることはできません。

確かに、これはエラーをスローします：

しかし、UTC の神々によると、これはリアルタイムになります。イベントは で発生する可能性があります23:59:60が、この事実を記録する方法はありません。

23:59:59プラス 1 秒のオフセットは、7 月 1 日でも考慮00:00:00されます。

23:59:60データベースでイベントが発生したことを正しく記録するにはどうすればよいですか?

そのため、つい最近、pthread_mutex_timedlock に依存する非同期サーバー コードが時期尚早にタイムアウトしたようです。最初は自分のバグだと思っていましたが、Linux カーネルにうるう秒の問題があることを確認したところ、私だけではないようです: https://lkml.org/lkml/2012/7/1 /11

これに対する現在の修正は何ですか? サーバーを再起動しますか、それともカーネルを更新しますか? 私のサーバーは、他のスレッドからのイベントを待機するために timedlock メカニズムに依存しています。この時期尚早のタイムアウトにより、CPU 使用率は 100% になりました。

現在、カーネルバージョン2.6.39.1でubuntuサーバー10.04.4を実行しています

Leap SecondsDateTimeでいくつかの計算を行いたかったのですが、意味がわからなかったため、かなり早く停止しました。DateTime

出力：

DateTime昨年のその UTC 閏秒を作成できません(また、私が試した他の閏秒も作成できません)。DateTimeうるう秒をサポートするかどうか疑問に思った.UTCをサポートしていると思ったが、おそらくうるう秒をサポートしていないので、GMTのみをサポートしている？

Unix (POSIX) 時間に関して、ウィキペディアは次のように述べています。

うるう秒を処理するため、時間の線形表現でも UTC の真の表現でもありません。

しかし、Unixdateコマンドは実際にはそれらを認識していないようです。

にうるう秒があるはずですがMon Jun 30 23:59:60 UTC 1997。

これは、コマンドだけがdate閏秒を無視し、Unix 時間の概念は無視しないということですか?

うるう秒のタイムスタンプ datetime を持つデータを解析しています2012-06-30T23:59:60.209215。次のコードを使用して、その文字列を解析し、datetime オブジェクトに変換しました。

%SPython のドキュメントでは、これはacceptとして問題になるべきではないと主張しています[0, 61]。しかし、上記のタイムスタンプでこのエラーが発生します

ありがとう