Perché le classi java.time di Java 8 mancano di un metodo getMillis ()?

JSR-310 è basato su nanosecondi, non millisecondi. In quanto tale, l'insieme minimo di metodi sensibili si basa su ore, minuti, secondi e nanosecondi. La decisione di avere una base di nanosecondi è stata una delle decisioni originali del progetto, e credo fermamente che sia corretta.

L'aggiunta di un metodo per millis si sovrapporrebbe a quella del nanosecondo è un modo non ovvio. Gli utenti dovrebbero pensare se il campo nano fosse nano-di-secondo o nano-di-milli per esempio. L'aggiunta di un metodo aggiuntivo confuso non è auspicabile, quindi il metodo è stato omesso. Come indicato, è disponibile l'alternativa get(MILLI_OF_SECOND) .

FWIW, vorrei oppormi all'aggiunta del metodo getMillis() in futuro.

Prima di far parte di openJDK, threeten era in github e prima era su sourceforge. A quel tempo, Stephen Colebourne, che è una guida delle specifiche su jsr-310, ha fatto un sondaggio che è ancora possibile trovare sul sito 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

solo il 6,23% ha scelto la risposta n. 4 e tra questi circa il 15% ha chiesto un getMillis() , vale a dire meno dell'1% dei voti totali.

Questo è probabilmente il motivo per cui non c'era nessun getMillis in primo luogo e non sono riuscito a trovare nulla correlato sulla mailing list di openjdk, quindi la questione apparentemente non è stata discussa in seguito.

Le classi che rappresentano tempi UTC non ambigui (quelli Instant, OffsetDateTime, ZonedDateTime) hanno due metodi helper per accedere all'offset assoluto dell'epoca Java, ovvero quello che chiami 'millisecond time' in java.util.Date, che potresti usare per ottenere in millisecondi

long getEpochSecond()
int getNano()

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

Sono stati discussi alcuni motivi per cui questo è stato scelto al posto di long getEpochMillis() su la mailing list di jsr 310 , alcuni dei quali ho estratto per comodità:

it seems reasonable to suppose that milliseconds precision won't be sufficient. However, anything greater than nanosecond precision seems excessive

...

In order to implement this, my preferred option would be 64 bit long seconds (signed) + 32 bit int nanoseconds (unsigned).

...

I prefer the split to be at the second level as that is the official SI unit of time in science, and the most universally agreed standard.

Splitting at the days level is problematic for instants as it doesn't handle leap seconds. Splitting at the milliseconds level, while integrating slightly better with the rest of Java, seems really rather odd. Plus it loses in the supported range.

Splitting at the second as proposed, gives a range of instants of nanoseconds over 290 billion years. While nobody should ever use that precision over that range of the time-line, I'd suggest its easier to support it than to block it.splitting at the days level is problematic for instants as it doesn't handle leap seconds

Ho la sensazione che un altro motivo fosse quello di rendere intenzionalmente difficile la conversione da classi java.util.Date a JSR310, sperando che gli sviluppatori provassero a capire le differenze tra le varie opzioni e non solo ciecamente (errare) ad usare il nuove classi.

Sul motivo per cui la classe LocalDateTime non ha quei metodi - non possono esistere in questo caso perché LocalDateTime non è legato alla timeline UTC finché non decidi in quale zona ti trovi o quale sia il tuo offset UTC è, a quel punto hai te stesso un OffsetDateTime o ZonedDateTime (entrambi hanno i metodi necessari).

In alternativa, potresti definire la tua LOCAL_EPOCH costante a 1970-01-01T00:00:00 e poi fare un MILLIS.between(LOCAL_EPOCH, localTime) per ottenere una sorta di durata in millisecondi. Questo valore, tuttavia, non sarà compatibile con qualsiasi valore restituito da System.currentTimeMilliseconds() o java.util.Date.getTime() , a meno che, naturalmente, non si definisca l'ora locale come ora UTC; ma in questo caso potresti usare anche Instant direttamente o OffsetDateTime con ZoneOffset.UTC.