Tại sao các lớp java.time Java 8 thiếu phương thức getMillis ()?

Java 8 có một thư viện hoàn toàn mới về ngày và thời gian trong gói java.time, đây là điều rất đáng hoan nghênh cho bất kỳ ai đã phải sử dụng JodaTime trước đây hoặc gặp rắc rối với việc tạo các phương thức trợ giúp xử lý ngày của riêng nó. Nhiều lớp trong gói này đại diện cho dấu thời gian và có các phương thức trợ giúp như getHour()lấy giờ từ dấu thời gian, getMinute()để lấy phút từ dấu thời gian, getNano()để lấy nanos từ dấu thời gian, v.v ...

Tôi nhận thấy rằng họ không có một phương pháp nào được gọi là getMillis()lấy một phần triệu dấu thời gian. Thay vào đó người ta sẽ phải gọi phương thức get(ChronoField.MILLI_OF_SECOND). Đối với tôi nó có vẻ như một sự không nhất quán trong thư viện. Có ai biết tại sao một phương thức như vậy bị thiếu hay không, vì Java 8 vẫn đang được phát triển nên có khả năng nó sẽ được thêm vào sau không?

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

Các lớp được định nghĩa ở đây đại diện cho các khái niệm thời gian chính, bao gồm thời gian, thời lượng, ngày, thời gian, múi giờ và thời gian. Chúng dựa trên hệ thống lịch ISO, đây là lịch thế giới thực tế theo các quy tắc Gregorian phổ biến. Tất cả các lớp là bất biến và an toàn chủ đề.

Mỗi phiên bản thời gian ngày bao gồm các trường được API cung cấp một cách thuận tiện. Để truy cập cấp thấp hơn vào các trường tham khảo java.time.temporalgói. Mỗi lớp bao gồm hỗ trợ in và phân tích cú pháp tất cả các ngày và thời gian. Tham khảo java.time.formatgói cho các tùy chọn tùy chỉnh ...

Ví dụ về loại lớp học này:
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

Thời gian ngày không có múi giờ trong hệ thống lịch ISO-8601, chẳng hạn như 2007-12-03T10: 15: 30.

LocalDateTimelà một đối tượng thời gian ngày bất biến đại diện cho thời gian ngày, thường được xem là năm-tháng-ngày-giờ-phút-giây. Các trường ngày và giờ khác, chẳng hạn như ngày trong năm, ngày trong tuần và tuần, cũng có thể được truy cập. Thời gian được biểu diễn cho độ chính xác nano giây. Ví dụ: giá trị "ngày 2 tháng 10 năm 2007 lúc 13: 45.30.123456789" có thể được lưu trữ trong LocalDateTime...

JSR-310 dựa trên nano giây, không phải mili giây. Như vậy, tập hợp tối thiểu các phương pháp hợp lý dựa trên giờ, phút, giây và nano giây. Quyết định có cơ sở nano giây là một trong những quyết định ban đầu của dự án và là quyết định mà tôi tin tưởng là chính xác.

Thêm một phương pháp cho millis sẽ chồng lấp lên của nano giây là một cách không rõ ràng. Người dùng sẽ phải suy nghĩ xem liệu trường nano là nano giây hay nano-milli chẳng hạn. Thêm một phương thức bổ sung khó hiểu là không mong muốn, vì vậy phương pháp đã bị bỏ qua. Như đã chỉ ra, sự thay thế get(MILLI_OF_SECOND)có sẵn.

FWIW, tôi sẽ phản đối việc thêm getMillis()phương thức này trong tương lai.

Trước khi là một phần của openJDK, threeten đã ở trên github và trước đó nó đã ở trên sourceforge. Trước đó, Stephen Colebourne, người dẫn đầu về đặc điểm kỹ thuật trên jsr-310, đã thực hiện một cuộc khảo sát mà bạn vẫn có thể tìm thấy trên trang web 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

chỉ 6,23% chọn câu trả lời số 4 và trong số đó có khoảng 15% yêu cầu a getMillis(), tức là ít hơn 1% tổng số phiếu.

Đó có lẽ là lý do tại sao không có getMillisở nơi đầu tiên và tôi không thể tìm thấy bất cứ điều gì liên quan trong danh sách gửi thư openjdk vì vậy vấn đề rõ ràng không được thảo luận sau đó.

Các lớp biểu thị thời gian UTC không rõ ràng (đó là Instant, OffsetDateTime, ZencedDateTime) có hai phương thức trợ giúp để truy cập phần bù tuyệt đối từ epoch Java, tức là bạn gọi là 'mili giây' trong java.util.Date, mà bạn có thể sử dụng để có được ở mili giây

long getEpochSecond()
int getNano()

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

Một số lý do tại sao điều này đã được chọn thay vì long getEpochMillis()được thảo luận trong danh sách gửi thư jsr 310 , một số lý do tôi đã trích xuất để thuận tiện:

có vẻ hợp lý khi cho rằng độ chính xác của mili giây sẽ không đủ. Tuy nhiên, bất cứ điều gì lớn hơn độ chính xác của nano giây dường như quá mức

...

Để thực hiện điều này, tùy chọn ưa thích của tôi sẽ là 64 giây dài (đã ký) + 32 bit int nano giây (không dấu).

...

Tôi thích sự phân chia ở cấp độ thứ hai vì đó là đơn vị thời gian SI chính thức trong khoa học và là tiêu chuẩn được thống nhất phổ biến nhất.

Việc chia tách ở cấp độ ngày là vấn đề đối với các instants vì nó không xử lý các bước nhảy vọt. Chia tách ở mức mili giây, trong khi tích hợp tốt hơn một chút với phần còn lại của Java, có vẻ thực sự khá kỳ quặc. Thêm vào đó nó mất trong phạm vi được hỗ trợ.

Việc tách ra ở lần thứ hai như đề xuất, mang lại một loạt các phần tử nano giây trong hơn 290 tỷ năm. Mặc dù không ai nên sử dụng độ chính xác đó trong phạm vi dòng thời gian đó, tôi khuyên bạn nên hỗ trợ nó dễ dàng hơn là chặn nó. Việc chia tách ở cấp độ ngày là vấn đề đối với các instants vì nó không xử lý giây nhuận

Tôi có cảm giác rằng một lý do khác là cố tình chuyển đổi từ các lớp java.util.Date sang JSR 310, hy vọng rằng các nhà phát triển sẽ cố gắng hiểu sự khác biệt giữa các tùy chọn khác nhau và không chỉ sử dụng các lớp mới một cách mù quáng.

Về lý do tại sao LocalDateTimelớp không có các phương thức đó - chúng không thể tồn tại ở đó vì LocalDateTimekhông bị ràng buộc với dòng thời gian UTC cho đến khi bạn quyết định bạn đang ở khu vực nào hoặc phần bù UTC của bạn là gì, tại thời điểm đó bạn có cho mình một OffsetDateTimehoặc ZonedDateTime(cả hai đều có các phương thức cần thiết).

Ngoài ra, bạn có thể xác định bạn sở hữu LOCAL_EPOCHhằng số 1970-01-01T00:00:00và sau đó thực hiện MILLIS.between(LOCAL_EPOCH, localTime)để có được một số loại thời lượng tính bằng mili giây. Tuy nhiên, giá trị này sẽ không tương thích với bất kỳ giá trị nào được trả về bởi System.currentTimeMilliseconds()hoặc java.util.Date.getTime(), trừ khi tất nhiên bạn xác định giờ địa phương của mình là giờ UTC; nhưng trong trường hợp này, bạn cũng có thể sử dụng Instant trực tiếp hoặc OffsetDateTime với Zone Offerset.UTC.