Java 8 java.timeクラスにgetMillis（）メソッドがないのはなぜですか？

Java 8には、パッケージjava.timeに日付と時刻のまったく新しいライブラリがあります。これは、以前にJodaTimeを使用したり、独自の日付処理ヘルパーメソッドを作成したりする必要があるユーザーにとって非常に歓迎されるものです。このパッケージの多くのクラスはタイムスタンプを表し、タイムスタンプgetHour()から時間getMinute()を取得する、タイムスタンプから分を取得する、タイムスタンプからナノを取得するなどのヘルパーメソッドを持っていgetNano()ます...

getMillis()タイムスタンプのミリ秒を取得するために呼び出されるメソッドがないことに気付きました。代わりに、methodを呼び出す必要がありますget(ChronoField.MILLI_OF_SECOND)。私には、図書館の矛盾のように思えます。そのようなメソッドが欠落している理由を誰かが知っていますか、またはJava 8がまだ開発中であるため、後で追加される可能性がありますか？

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

ここで定義されているクラスは、インスタント、期間、日付、時刻、タイムゾーン、期間など、主要な日時の概念を表しています。これらはISOカレンダーシステムに基づいています。これは、予言的なグレゴリオ暦のルールに基づいた事実上の世界カレンダーです。すべてのクラスは不変であり、スレッドセーフです。

各日時インスタンスは、APIによって便利に利用できるようになっているフィールドで構成されています。フィールドへの低レベルのアクセスについては、java.time.temporalパッケージを参照してください。各クラスには、あらゆる種類の日付と時刻の印刷と解析のサポートが含まれています。java.time.formatカスタマイズオプションについては、パッケージを参照してください...

この種類のクラスの例：https :
//docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

2007-12-03T10：15：30など、ISO-8601カレンダーシステムのタイムゾーンのない日時。

LocalDateTimeは、日時を表す不変の日時オブジェクトであり、多くの場合、年月日日時分秒として表示されます。年間通算日、曜日、通年など、他の日付および時刻フィールドにもアクセスできます。時間はナノ秒の精度で表されます。たとえば、「2007年10月2日13：45.30.123456789」という値は、LocalDateTime...

JSR-310は、ミリ秒ではなくナノ秒に基づいています。そのため、賢明なメソッドの最小セットは、時間、分、秒、ナノ秒に基づいています。ナノ秒ベースを持つという決定は、プロジェクトの最初の決定の1つであり、正しいと強く信じています。

ミリ秒のメソッドを追加すると、ナノ秒のメソッドと重複しますが、これは明らかではありません。ユーザーは、例えばナノフィールドがナノ秒かナノミリかを考えなければなりません。混乱を招く追加メソッドを追加することは望ましくないため、このメソッドは省略されました。指摘したように、代替手段get(MILLI_OF_SECOND)が利用可能です。

FWIW、私はgetMillis()将来メソッドを追加することに反対します。

openJDKに参加する前は、threetenはgithubにあり、それ以前はsourceforgeにありました。当時、jsr-310の仕様リードであるStephen Colebourneは、sourceforgeサイトで引き続き調査できるアンケートを作成しました。

The fourth question on the survey covered the method names for LocalTime:
1) getHourOfDay(), getMinuteOfHour(), getSecondOfMinute(), getNanoOfSecond()
2) getHour(), getMinute(), getSecond(), getNanoOfSecond()
3) getHour(), getMinute(), getSecond(), getNano()
4) another idea

回答＃4を選択したのは6.23％のみで、そのうち約15％がaを求めましたgetMillis()。つまり、総投票数の1％未満です。

それがおそらくgetMillisそもそも何もなかった理由であり、openjdkメーリングリストで関連するものを見つけることができなかったので、問題はその後議論されなかったようです。

明確なUTC時間（インスタント、OffsetDateTime、ZonedDateTime）を表すクラスには、Javaエポックからの絶対オフセットにアクセスするための2つのヘルパーメソッド、つまりjava.util.Dateで「ミリ秒時間」と呼ばれるものがありますミリ秒で取得する

long getEpochSecond()
int getNano()

1000L*getEpochSecond() + getNano() / 1000000L;

これが代わりに選択された理由に関するいくつかの理由long getEpochMillis()については、、jsr 310メーリングリストでた。

ミリ秒の精度では十分ではないと想定するのが妥当と思われます。ただし、ナノ秒の精度を超えるものは過剰に思えます

...

これを実装するための推奨オプションは、64ビット長秒（符号付き）+ 32ビット整数ナノ秒（符号なし）です。

...

科学における公式のSI時間単位であり、最も普遍的に合意された標準であるため、私は分割が第2レベルにあることを好みます。

日レベルでの分割は、うるう秒を処理しないため、インスタントでは問題があります。ミリ秒レベルでの分割は、Javaの他の部分との統合がわずかに優れていますが、かなり奇妙に思えます。さらに、サポートされている範囲内で失われます。

提案されたように秒単位で分割すると、2900億年にわたってナノ秒の範囲の瞬間が得られます。誰もタイムラインのその範囲でその精度を使用するべきではありませんが、それをブロックするよりもサポートする方が簡単であることをお勧めします。日レベルでの分割は、うるう秒を処理しないため、インスタントにとって問題です

開発者が新しいクラスを盲目的に（誤って）使用するだけでなく、さまざまなオプションの違いを理解しようとすることを期待して、意図的にjava.util.DateからJSR310クラスに変換することを困難にすることも別の理由であると感じています。

LocalDateTimeクラスにこれらのメソッドがない理由については、LocalDateTimeあなたがいるゾーンまたはUTCオフセットが何であるかを決定するまでUTCタイムラインに関連付けられていないため、それらが存在しない可能性がありますOffsetDateTimeまたはZonedDateTime（どちらにも必要なメソッドがあります）。

または、独自のLOCAL_EPOCH定数を定義1970-01-01T00:00:00してMILLIS.between(LOCAL_EPOCH, localTime)からa を実行し、ミリ秒単位で何らかの持続時間を取得することもできます。ただし、もちろんローカル時間をUTC時間に定義しない限り、この値はSystem.currentTimeMilliseconds()またはによって返される値と互換性がありませんjava.util.Date.getTime()。ただし、この場合は、Instantを直接使用するか、OffsetDateTimeをZoneOffset.UTCで使用することもできます。