Por que as classes Java 8 java.time estão ausentes do método getMillis ()?

O Java 8 tem uma biblioteca totalmente nova para datas e horas no pacote java.time, o que é muito bem-vindo para quem já teve que usar o JodaTime antes ou se incomodou em criar seus próprios métodos auxiliares de processamento de datas. Muitas classes neste pacote representam registros de data e hora e têm métodos auxiliares como getHour()obter horas do registro de data e hora, getMinute()minutos do registro de data e hora, getNano()obter nanos do registro de data e hora, etc ...

Notei que eles não têm um método chamado getMillis()para obter o milésimo de tempo. Em vez disso, seria preciso chamar o método get(ChronoField.MILLI_OF_SECOND). Para mim, parece uma inconsistência na biblioteca. Alguém sabe por que esse método está faltando ou como o Java 8 ainda está em desenvolvimento, existe a possibilidade de ser adicionado posteriormente?

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

As classes definidas aqui representam os principais conceitos de data e hora, incluindo instantes, durações, datas, horas, fusos horários e períodos. Eles são baseados no sistema de calendário ISO, que é o calendário mundial de fato, seguindo as regras gregorianas pró-sépticas. Todas as classes são imutáveis ​​e seguras para threads.

Cada instância de data e hora é composta por campos que são convenientemente disponibilizados pelas APIs. Para acesso de nível inferior aos campos, consulte o java.time.temporalpacote. Cada aula inclui suporte para impressão e análise de todos os tipos de datas e horas. Consulte o java.time.formatpacote para opções de personalização ...

Exemplo deste tipo de classe:
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

Uma data e hora sem fuso horário no sistema de calendário ISO-8601, como 2007-12-03T10: 15: 30.

LocalDateTimeé um objeto de data e hora imutável que representa uma data e hora, geralmente vista como ano-mês-dia-hora-hora-minuto-segundo. Outros campos de data e hora, como dia do ano, dia da semana e semana do ano, também podem ser acessados. O tempo é representado com precisão de nanossegundos. Por exemplo, o valor "2 de outubro de 2007 às 13: 45.30.123456789" pode ser armazenado em um LocalDateTime...

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

Adicionar um método para milis se sobrepõe ao de nanossegundos é uma maneira não óbvia. Os usuários precisariam pensar se o campo nano era nano-de-segundo ou nano-de-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 getMillis()método no futuro.

Antes de fazer parte do openJDK, o threeten estava no github e antes no sourceforge. Naquela época, Stephen Colebourne, líder de especificação no jsr-310, fez uma pesquisa que você ainda pode encontrar no site do 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, dentre eles, aproximadamente 15% pediram a getMillis(), ou seja, menos de 1% do total de votos.

Provavelmente, é por isso que não havia, getMillisem primeiro lugar, e não encontrei nada relacionado na lista de discussão do openjdk, de modo que o assunto aparentemente não foi discutido posteriormente.

As classes que representam horários UTC inequívocos (Instant, OffsetDateTime, ZonedDateTime) têm dois métodos auxiliares para acessar o deslocamento absoluto da época Java, ou seja, o que você chama de 'milissegundo de tempo' no java.util.Date, que você pode usar para chegar em milissegundos

long getEpochSecond()
int getNano()

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

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

parece razoável supor que a precisão de milissegundos não será suficiente. No entanto, qualquer coisa maior que a precisão de nanossegundos parece excessiva

...

Para implementar isso, minha opção preferida seria segundos longos de 64 bits (assinado) + nanossegundos de 32 bits (sem sinal).

...

Prefiro que a divisão esteja no segundo nível, pois essa é a unidade oficial de tempo do SI na ciência e o padrão mais universalmente aceito.

A divisão no nível dos dias é problemática para os instantes, pois não lida com segundos bissextos. A divisão no nível de milissegundos, embora se integre um pouco melhor ao restante do Java, parece realmente bastante estranha. Além disso, perde na faixa suportada.

A divisão no segundo, conforme proposto, fornece uma variedade de instantes de nanossegundos durante 290 bilhões de anos. Embora ninguém jamais deva usar essa precisão nesse intervalo de tempo, sugiro que seja mais fácil apoiá-la do que bloqueá-la. Dividir no nível do dia é problemático para os instantes, pois não lida com segundos bissextos

Sinto que outro motivo foi intencionalmente dificultar a conversão das classes java.util.Date para JSR310, esperando que os desenvolvedores tentassem entender as diferenças entre as várias opções e não apenas usar cegamente as novas classes.

Por que a LocalDateTimeclasse não possui esses métodos - eles não podem existir lá porque LocalDateTimenão está vinculada à linha do tempo UTC até você decidir em que zona está ou qual é o seu deslocamento UTC; nesse momento, você tem um OffsetDateTimeou ZonedDateTime(ambos com os métodos necessários).

Como alternativa, você pode definir sua própria LOCAL_EPOCHconstante 1970-01-01T00:00:00e, 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 qualquer valor retornado por System.currentTimeMilliseconds()ou java.util.Date.getTime(), a menos que você defina sua hora local como UTC; mas, nesse caso, você também pode usar o Instant diretamente ou OffsetDateTime com ZoneOffset.UTC.