Por que as classes Java.time do Java 8 não possuem um método getMillis ()?

O JSR-310 é baseado em nanossegundos, não em milissegundos. Como tal, o conjunto mínimo de métodos sensíveis baseia-se em horas, minutos, segundos e nanossegundos. A decisão de ter uma base de nanossegundo foi uma das decisões originais do projeto e uma que acredito ser correta.

Adicionar um método para millis iria sobrepor o nanossegundo de uma maneira não óbvia. Os usuários teriam que pensar se o nano-field era nano-de-segundo ou nano-milli por exemplo. Adicionar um método adicional confuso não é desejável, portanto, o método foi omitido. Como apontado, a alternativa get(MILLI_OF_SECOND) está disponível.

FWIW, eu me oporia a adicionar o método getMillis() no futuro.

Antes de fazer parte do openJDK, threeten estava no github e antes disso estava no sourceforge. Naquela época, Stephen Colebourne, que é líder de especificação no jsr-310, fez uma pesquisa que ainda pode encontrar no site site 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

apenas 6,23% escolheram a resposta # 4 e entre eles aproximadamente 15% pediram getMillis() , ou seja, menos de 1% do total de votos.

É provavelmente por isso que não houve getMillis em primeiro lugar e não consegui encontrar nada relacionado na lista de discussão openjdk, então o assunto aparentemente não foi discutido posteriormente.

As classes que representam tempos UTC não ambíguos (são Instant, OffsetDateTime, ZonedDateTime) têm dois métodos auxiliares para acessar o deslocamento absoluto da época de Java, ou seja, o que você chama de 'milissegundos' no java.util.Date, que você poderia usar para chegar a milissegundos

long getEpochSecond()
int getNano()

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

Algumas razões do porque isso foi escolhido em vez de long getEpochMillis() foram discutidas em a lista de discussão jsr 310 , algumas das quais eu extraímos por conveniência:

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

Tenho a sensação de que outra razão foi tornar intencionalmente difícil converter de java.util.Date em classes JSR310, esperando que os desenvolvedores tentassem entender as diferenças entre as várias opções e não apenas cegamente (mal) usar as novas classes.

Por que a classe LocalDateTime não tem esses métodos? Eles não podem existir porque LocalDateTime não está vinculado à linha do tempo da UTC até que você decida em qual zona você está ou qual o seu deslocamento UTC é, em que ponto você tem um OffsetDateTime ou ZonedDateTime (ambos com os métodos necessários).

Como alternativa, você pode definir sua própria LOCAL_EPOCH constant para 1970-01-01T00:00:00 e, em seguida, fazer um MILLIS.between(LOCAL_EPOCH, localTime) para obter algum tipo de duração em milissegundos. Esse valor, no entanto, não será compatível com nenhum valor retornado por System.currentTimeMilliseconds() ou java.util.Date.getTime() , a menos que você defina sua hora local como a hora UTC; mas neste caso você também pode usar Instant diretamente ou OffsetDateTime com ZoneOffset.UTC.