Perché alle classi java.time di Java 8 manca un metodo getMillis ()?

Java 8 ha una libreria completamente nuova per le date e gli orari nel pacchetto java.time, il che è molto gradito a chiunque abbia dovuto usare JodaTime prima o seccarsi nel creare i propri metodi di supporto per l'elaborazione delle date. Molte classi in questo pacchetto rappresentano timestamp e hanno metodi di supporto come getHour()ottenere ore da timestamp, getMinute()ottenere minuti da timestamp, getNano()ottenere nanos da timestamp ecc ...

Ho notato che non hanno un metodo chiamato getMillis()per ottenere i millesimi di time stamp. Invece si dovrebbe chiamare il metodo get(ChronoField.MILLI_OF_SECOND). A me sembra un'incoerenza nella biblioteca. Qualcuno sa perché manca un tale metodo, o poiché Java 8 è ancora in fase di sviluppo c'è la possibilità che verrà aggiunto in seguito?

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

Le classi qui definite rappresentano i principali concetti data-ora, inclusi istanti, durate, date, orari, fusi orari e periodi. Si basano sul sistema del calendario ISO, che è di fatto il calendario mondiale che segue le proletiche regole gregoriane. Tutte le classi sono immutabili e thread-safe.

Ogni istanza di data e ora è composta da campi resi disponibili dalle API. Per un accesso di livello inferiore ai campi fare riferimento al java.time.temporalpacchetto. Ogni classe include il supporto per la stampa e l'analisi di tutti i tipi di date e orari. Fare riferimento al java.time.formatpacchetto per le opzioni di personalizzazione ...

Esempio di questo tipo di classe:
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

Una data-ora senza fuso orario nel sistema di calendario ISO-8601, come 2007-12-03T10: 15: 30.

LocalDateTimeè un oggetto data-ora immutabile che rappresenta una data-ora, spesso vista come anno-mese-giorno-ora-minuto-secondo. È inoltre possibile accedere ad altri campi di data e ora, come il giorno dell'anno, il giorno della settimana e la settimana dell'anno. Il tempo è rappresentato dalla precisione dei nanosecondi. Ad esempio, il valore "2 ottobre 2007 alle 13: 45.30.123456789" può essere memorizzato in un LocalDateTime...

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

L'aggiunta di un metodo per il millis sovrapposizione a quello 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 sottolineato, l'alternativa get(MILLI_OF_SECOND)è disponibile.

FWIW, mi oppongo all'aggiunta del getMillis()metodo in futuro.

Prima di far parte di openJDK, Threeten era su Github e prima ancora su Sourceforge. All'epoca Stephen Colebourne, che è un responsabile delle specifiche su jsr-310, ha realizzato un sondaggio che è ancora possibile trovare sul sito di 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 a getMillis(), ovvero meno dell'1% dei voti totali.

Questo è probabilmente il motivo per cui non ce getMillisn'era in primo luogo e non sono riuscito a trovare nulla di simile nella mailing list di openjdk, quindi apparentemente la questione non è stata discussa in seguito.

Le classi che rappresentano i tempi UTC non ambigui (quelli sono Instant, OffsetDateTime, ZonedDateTime) hanno due metodi di supporto per accedere all'offset assoluto dall'epoca Java, vale a dire ciò che si chiama 'millisecond time' in java.util.Date, che è possibile utilizzare per arrivare a millisecondi

long getEpochSecond()
int getNano()

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

Alcuni motivi per cui questo è stato scelto invece di long getEpochMillis()sono stati discussi nella mailing list jsr 310 , alcuni dei quali ho estratto per comodità:

sembra ragionevole supporre che la precisione in millisecondi non sia sufficiente. Tuttavia, qualsiasi cosa superiore alla precisione dei nanosecondi sembra eccessiva

...

Per implementare questo, la mia opzione preferita sarebbe 64 secondi lunghi (con segno) + 32 bit int nanosecondi (senza segno).

...

Preferisco che la divisione sia al secondo livello in quanto questa è l'unità di tempo ufficiale della scienza nella scienza, e lo standard più universalmente concordato.

La divisione a livello di giorni è problematica per gli istanti in quanto non gestisce i secondi bisestili. Dividere a livello di millisecondi, pur integrandosi leggermente meglio con il resto di Java, sembra davvero piuttosto strano. Inoltre perde nell'intervallo supportato.

La divisione al secondo, come proposto, offre una gamma di istanti di nanosecondi oltre 290 miliardi di anni. Mentre nessuno dovrebbe mai usare quella precisione su quell'intervallo di tempo, suggerirei che è più facile supportarlo che bloccarlo. La suddivisione a livello di giorni è problematica per gli istanti in quanto non gestisce i secondi bisestili

Ho la sensazione che un altro motivo sia stato quello di rendere intenzionalmente difficile la conversione da java.util.Date alle classi JSR310, sperando che gli sviluppatori avrebbero cercato di capire le differenze tra le varie opzioni e non solo di usare ciecamente (mis) le nuove classi.

Per quanto riguarda il motivo per cui la LocalDateTimeclasse non ha questi metodi - non possono probabilmente esistere lì perché LocalDateTimenon è legata alla linea temporale UTC fino a quando non decidi in quale zona ti trovi o quale sia il tuo offset UTC, a quel punto hai un OffsetDateTimeo ZonedDateTime(entrambi i quali hanno i metodi necessari).

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