Java 8 java.time 클래스에 getMillis () 메소드가없는 이유는 무엇입니까?

Java 8에는 java.time 패키지에 날짜 및 시간에 대한 완전히 새로운 라이브러리가 있으며, 이전에 JodaTime을 사용하거나 자체 날짜 처리 도우미 메소드를 작성 해야하는 번거 로움이있는 사람에게는 매우 환영합니다. 이 패키지의 많은 클래스는 타임 스탬프를 나타내며 타임 스탬프 getHour()에서 시간 을 가져 오거나 getMinute()타임 스탬프에서 분 getNano()을 가져 오거나 타임 스탬프 등에서 나노를 얻는 등의 도우미 메서드를 가지고 있습니다 .

getMillis()타임 스탬프의 밀리 초를 얻기 위해 호출 된 메소드가 없다는 것을 알았습니다 . 대신 method를 호출해야합니다 get(ChronoField.MILLI_OF_SECOND). 나에게 그것은 도서관의 불일치처럼 보인다. 왜 그러한 메소드가 누락되었거나 Java 8이 아직 개발 중이므로 나중에 추가 될 가능성이 있습니까?

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

여기에 정의 된 클래스는 인스턴트, 기간, 날짜, 시간, 시간대 및 기간을 포함한 주요 날짜-시간 개념을 나타냅니다. 그것들은 ISO 달력 시스템을 기반으로하며, 이는 다발적인 Gregorian 규칙을 따르는 사실상의 세계 달력입니다. 모든 클래스는 변경 불가능하고 스레드로부터 안전합니다.

각 날짜 시간 인스턴스는 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불변의 날짜-시간 객체로, 일-월-일-시-분-초로 표시되는 날짜-시간을 나타냅니다. 년, 요일 및 주와 같은 다른 날짜 및 시간 필드에도 액세스 할 수 있습니다. 시간은 나노초 정밀도로 표시됩니다. 예를 들어, "2007 년 10 월 2 일 13 : 45.30.123456789"의 값은 LocalDateTime...

JSR-310 은 밀리 초가 아닌 나노초를 기반으로합니다. 따라서, 현명한 방법의 최소 세트는시, 분, 초 및 나노초를 기준으로합니다. 나노초 단위를 사용하기로 한 결정은 프로젝트의 원래 결정 중 하나였으며 제가 옳다고 생각합니다.

밀리 초에 대한 방법을 추가하면 나노초의 방법과 겹치게됩니다. 사용자는 예를 들어 나노 필드가 나노초인지 나노 밀리인지에 대해 생각해야 할 것입니다. 혼란스러운 추가 방법을 추가하는 것은 바람직하지 않으므로 방법을 생략했습니다. 지적했듯이 대안 get(MILLI_OF_SECOND)을 사용할 수 있습니다.

FWIW, 나는 getMillis()미래에 방법을 추가하는 것에 반대 할 것입니다.

openJDK에 참여하기 전에 threeten은 github에 있었고 그 이전에는 sourceforge에있었습니다. 그 당시 jsr-310의 사양 책임자 인 Stephen Colebourne은 여전히 소스 포지 사이트에서 찾을 수있는 설문 조사를 실시했습니다 .

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 epoch에서 절대 오프셋에 액세스하기위한 두 가지 도우미 메소드가 있습니다. 즉, java.util.Date에서 'millisecond time'이라고 부르는 것입니다. 밀리 초에 도달

long getEpochSecond()
int getNano()

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

이것이 대신 선택된 이유에 대한 몇 가지 이유 는 jsr 310 메일 링리스트 에서 long getEpochMillis()논의되었으며 , 그 중 일부는 편의상 추출한 것입니다.

밀리 초 정밀도가 충분하지 않다고 가정하는 것이 합리적입니다. 그러나 나노초 정밀도보다 큰 것은 과도하게 보입니다.

...

이것을 구현하기 위해 선호하는 옵션은 64 비트 긴 초 (서명) + 32 비트 int 나노 초 (서명되지 않음)입니다.

...

저는 과학 분야의 공식 SI 시간 단위이며 가장 보편적으로 합의 된 표준이기 때문에 두 번째 수준에있는 것을 선호합니다.

요일 수준에서 분할하는 것은 윤초를 처리하지 않기 때문에 순간적으로 문제가됩니다. 밀리 초 수준으로 분할하면 나머지 Java와 약간 더 잘 통합되지만 실제로는 다소 이상한 것 같습니다. 또한 지원되는 범위에서 손실됩니다.

제안 된대로 초 단위로 분할하면 2 억 2 천 2 백만 년에 걸쳐 나노초의 순간 범위를 제공합니다. 아무도 그 타임 라인 범위에서 그 정밀도를 사용해서는 안되지만, 그것을 차단하는 것보다 그것을 지원하는 것이 더 쉽다고 제안합니다. 일 수준에서 나누는 것은 윤초를 처리하지 않기 때문에 순간에 문제가됩니다.

개발자가 새로운 옵션을 맹목적으로 (잘못) 사용하지 않고 다양한 옵션의 차이점을 이해하려고하기를 희망하면서 또 다른 이유는 java.util.Date에서 JSR310 클래스로 변환하기가 의도적으로 어렵다는 느낌이 있습니다.

LocalDateTime클래스 에 왜 그런 메소드가 없는지에 관해서는 -존재 LocalDateTime하는 영역이나 UTC 오프셋이 무엇인지 결정할 때까지 UTC 타임 라인에 묶여 있지 않기 때문에 거기에 존재할 수 없습니다 . OffsetDateTime또는 ZonedDateTime(둘 다 필요한 방법이 있음).

또는 LOCAL_EPOCH상수를 정의 1970-01-01T00:00:00한 다음 MILLIS.between(LOCAL_EPOCH, localTime)밀리 초 단위의 지속 시간을 얻기 위해 a 를 수행 할 수 있습니다. 그러나이 값은 현지 시간을 UTC 시간으로 정의하지 않는 한 System.currentTimeMilliseconds()또는 java.util.Date.getTime()에 의해 반환 된 값과 호환되지 않습니다 . 그러나이 경우 Instant를 직접 사용하거나 ZoneOffset.UTC와 함께 OffsetDateTime을 사용할 수도 있습니다.