new Date()うるう秒の前と最中に、 23:59:59 と 23:59:60 ではなく、呼び出しによって 23:59:59 が 2 回 (うるう秒の前に 1 回、うるう秒のときに 1 回) 返されるようです。
23:59 を正しく表示するために、指定された秒がうるう秒であるかどうかを判断する方法はありますか (アプリケーション内に NTP クライアントを実装するか、時計が逆行するか繰り返すかを確認する方法はありません)。 :60 ユーザーに?
さらに言えば、ホスト オペレーティング システムには、うるう秒の前か後かを判断するためのフックがありますか?
のソースコードを見てみましょうjava.util.Date:
public Date() {
this(System.currentTimeMillis());
}
したがって、質問は次のように読むことができます。
System.currentTimeMillis()閏秒の値は 60 または 61 (仕様がふりをしているように) になりますか?
厳密な意味での答えは、基盤となるオペレーティング システムに依存します。しかし、実際には、Windows、Linux、Apple、Android などのよく知られているオペレーティング システムはすべて、うるう秒を認識していません。代わりに、これらのオペレーティング システムは、いつでも任意のクロック操作を行います (元に戻すなど、NTP サーバーとの同期など)。したがって、 -APIを使用してうるう秒を観察することはありません。Dateちなみに、値 61 は不可能です。UTC 標準では、UTC が UT1 から 0.9 秒以上逸脱しないことが義務付けられており、その結果、2 重のうるう秒が挿入されないからです。
「61」の起源は、初期の POSIX 仕様からの大きな誤解です (この間違いは現在修正されています)。残念ながら、古い Java 仕様はまだ修正されておらず、現在まで誤解を招いています。
Java-8 について:
はい、いわゆる「Java Time-Scale」は正式に UTC-SLS として指定されています - その意図はむしろ NTP サーバーの内部実装に向けられた期限切れの提案に基づいています。UTC-SLS の実装は現実の世界には存在しません。Java-8でさえUTC-SLS を実装していません。2 つの事実がこの声明を証明しています。
Java-8 にはうるう秒テーブルが含まれていません (これは UTC-SLS 実装の基礎となります)。Threeten-project はもともとそのようなものを保持していましたが、削除されました (現在は backport からも削除されています)。
java.util.Dateからへの変換Instantはちょうど 1:1 です (ソース コードを参照してください - 異なる精度のミリとナノは別として)。いわゆる「Java Time scale」に関してjava.util.DateのAPIでは言及されていないことに注意してください。Instant
Java タイムスケールは、すべての日時クラスに使用されます。これには、Instant、LocalDate、LocalTime、OffsetDateTime、ZonedDateTime、および Duration が含まれます。
さらに: の起源java.util.Dateは 1995 年 (Java が発明されたとき) ですが、UTC-SLS は数年後に提案されました。
では、うるう秒のサポートとして Java-8 に何が残されているのでしょうか? スペック内の空の単語は多くの混乱を引き起こします。他には何もありません。
他に何ができますか？JDKの範囲内では、何もありません。必要なのは、うるう秒データが組み込まれた外部サードパーティ ライブラリです。例は、私のライブラリ Time4J です。この記事を参照してください。もう 1 つのオプションは、クラスUTCInstantを持つライブラリ Threeten-Extraです。しかし、私はその変換をテストしていませんjava.util.Date(疑わしいと思われますか?)。
Date クラスの Java8 ドキュメントによると、うるう秒の間に Date を呼び出すと、正しく :60 または :61 が返されます。
したがって、何もする必要はありません。
基礎となるInstant クラスはうるう秒を 1 日の最後の 1000 秒に分散するため、実際には最後の 1 秒は 1.001 秒の長さになります。うるう秒かどうか。