Почему в классах Java 8 java.time отсутствует метод getMillis ()?

Java 8 имеет совершенно новую библиотеку для дат и времени в пакете java.time, что очень приветствуется для всех, кому раньше приходилось использовать JodaTime или из-за необходимости создавать собственные вспомогательные методы обработки дат. Многие классы в этом пакете представляют временные метки и имеют вспомогательные методы, такие как getHour()получение часов из временной метки, getMinute()получение минут из временной метки, getNano()получение наночастиц из временной метки и т. Д.

Я заметил, что у них нет метода, вызываемого getMillis()для получения миллис метки времени. Вместо этого нужно было бы вызвать метод 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.

Дата-время без часового пояса в календарной системе ISO-8601, например 2007-12-03T10: 15: 30.

LocalDateTimeявляется неизменным объектом даты-времени, который представляет дату-время, часто рассматриваемый как год-месяц-день-час-минута-секунда. Другие поля даты и времени, такие как день года, день недели и неделя года, также могут быть доступны. Время представляется с точностью до наносекунды. Например, значение «2 октября 2007 в 13: 45.30.123456789» может быть сохранено в LocalDateTime...

JSR-310 основан на наносекундах, а не миллисекундах. Таким образом, минимальный набор разумных методов основан на часах, минутах, секундах и наносекундах. Решение о создании наносекундной базы было одним из первоначальных решений проекта, и я убежден, что это правильно.

Добавление метода для миллиса будет перекрывать метод наносекунды - неочевидный способ. Пользователи должны будут думать о том, было ли нано поле нано секунды или нано милли миллиметров, например. Добавление запутанного дополнительного метода нежелательно, поэтому этот метод был опущен. Как указано, альтернатива get(MILLI_OF_SECOND)доступна.

FWIW, я был бы против добавления getMillis()метода в будущем.

До того, как стать частью openJDK, Threeten был на GitHub, а до этого он был на SourceForge. Тогда Стивен Колебурн, ведущий специалист по спецификации на jsr-310, провел опрос, который все еще можно найти на сайте 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

только 6,23% выбрали ответ № 4, и среди них примерно 15% попросили ответить getMillis(), т. е. менее 1% от общего числа голосов.

Вероятно, поэтому и не было, getMillisво-первых, и я не смог найти ничего связанного в списке рассылки openjdk, поэтому вопрос, по-видимому, впоследствии не обсуждался.

Классы, которые представляют однозначное время UTC (это Instant, OffsetDateTime, ZonedDateTime), имеют два вспомогательных метода для доступа к абсолютному смещению эпохи Java, то есть то, что вы называете «миллисекундным временем» в java.util.Date, которое вы можете использовать чтобы получить в миллисекундах

long getEpochSecond()
int getNano()

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

Некоторые причины того, почему это было выбрано вместо того, чтобы long getEpochMillis()обсуждаться в списке рассылки jsr 310 , некоторые из которых я извлек для удобства:

кажется разумным предположить, что точность в миллисекундах не будет достаточной. Однако что-то большее, чем наносекундная точность кажется чрезмерным

...

Чтобы реализовать это, я предпочел бы 64-битные длинные секунды (со знаком) + 32-битные инт наносекунды (без знака).

...

Я предпочитаю разделение на втором уровне, поскольку это официальная единица времени СИ в науке и наиболее универсально согласованный стандарт.

Разделение на уровне дней проблематично для моментов, поскольку оно не обрабатывает високосные секунды. Расщепление на уровне миллисекунд, хотя и немного лучше интегрируется с остальной частью Java, кажется довольно странным. Плюс он проигрывает в поддерживаемом диапазоне.

Расщепление на секунду, как предложено, дает диапазон мгновенных наносекунд за 290 миллиардов лет. Хотя никто никогда не должен использовать эту точность в этом диапазоне временной шкалы, я бы посоветовал ее легче поддерживать, чем блокировать. Разделение на уровне дней проблематично для мгновенных моментов, поскольку не обрабатывает дополнительных секунд

У меня есть ощущение, что другой причиной было намеренное затруднить преобразование классов java.util.Date в классы JSR310, в надежде, что разработчики попытаются понять различия между различными вариантами, а не просто слепо (неправильно) использовать новые классы.

Относительно того, почему у LocalDateTimeкласса нет этих методов - они не могут существовать там, потому что LocalDateTimeне привязаны к временной шкале UTC, пока вы не решите, в какой зоне вы находитесь или каково ваше смещение UTC, в какой момент вы сами OffsetDateTimeили ZonedDateTime(оба из которых имеют необходимые методы).

В качестве альтернативы, вы можете определить свою собственную LOCAL_EPOCHконстанту 1970-01-01T00:00:00и затем сделать a, MILLIS.between(LOCAL_EPOCH, localTime)чтобы получить некоторую продолжительность в миллисекундах. Это значение, однако, не будет совместимо с каким-либо значением, возвращаемым System.currentTimeMilliseconds()или java.util.Date.getTime(), если, конечно, вы не определите свое местное время как время UTC; но в этом случае вы также можете использовать Instant напрямую или OffsetDateTime с ZoneOffset.UTC.