Sự khác biệt giữa ZencedDateTime và OffsetDateTime là gì?

Tôi đã đọc tài liệu này, nhưng tôi vẫn không thể nhận được khi nào nên sử dụng cái này hay cái khác:

• OffsetDateTime
• ZonedDateTime

Theo tài liệu OffsetDateTimenên được sử dụng khi viết ngày vào cơ sở dữ liệu, nhưng tôi không hiểu tại sao.

Hỏi: Sự khác biệt giữa java 8 ZencedDateTime và OffsetDateTime là gì?

Các javadocs nói điều này:

" OffsetDateTime, ZonedDateTimeVà Instanttất cả các cửa hàng ngay lập tức trên dòng thời gian để chính xác nano giây. InstantLà đơn giản nhất, chỉ đơn giản là thể hiện ngay lập tức. OffsetDateTimeThêm vào ngay lập tức bù đắp từ UTC / Greenwich, cho phép các địa phương ngày-thời gian để có được. ZonedDateTimeCho biết thêm toàn thời gian quy tắc -zone. "

Nguồn: https://docs.oracle.com/javase/8/docs/api/java/time/ OffersetDateTime.html

Do đó, sự khác biệt giữa OffsetDateTimevà ZonedDateTimelà cái sau bao gồm các quy tắc bao gồm các điều chỉnh thời gian tiết kiệm ánh sáng ban ngày và các bất thường khác.

Nói một cách đơn giản:

Múi giờ = ( Offset-From-UTC + Rules-For-Anomalies)

H: Theo tài liệu OffsetDateTimenên được sử dụng khi ghi ngày vào cơ sở dữ liệu, nhưng tôi không hiểu tại sao.

Ngày có thời gian bù giờ địa phương luôn đại diện cho cùng một thời điểm, và do đó có một trật tự ổn định. Ngược lại, ý nghĩa của ngày với thông tin múi giờ đầy đủ là không ổn định khi điều chỉnh các quy tắc cho các múi giờ tương ứng. (Và những điều này xảy ra; ví dụ: đối với các giá trị thời gian trong tương lai.) Vì vậy, nếu bạn lưu trữ và sau đó truy xuất ZonedDateTimethì việc triển khai có vấn đề:

• Nó có thể lưu trữ phần bù được tính toán ... và đối tượng được truy xuất có thể có phần bù không phù hợp với các quy tắc hiện tại cho id vùng.

• Nó có thể loại bỏ phần bù được tính toán ... và đối tượng được truy xuất sau đó biểu thị một điểm khác trong dòng thời gian tuyệt đối / phổ quát so với điểm được lưu trữ.

Nếu bạn sử dụng tuần tự hóa đối tượng Java, việc triển khai Java 9 có cách tiếp cận đầu tiên. Đây được cho là cách "chính xác hơn" để xử lý việc này, nhưng điều này dường như không được ghi lại. (Trình điều khiển JDBC và các ràng buộc ORM có lẽ đang đưa ra các quyết định tương tự và hy vọng sẽ làm cho đúng.)

Nhưng nếu bạn đang viết một ứng dụng lưu trữ thủ công các giá trị ngày / thời gian hoặc dựa vào java.sql.DateTimeđó, thì việc xử lý các biến chứng của id khu vực là ... có lẽ nên tránh. Do đó lời khuyên.

Lưu ý rằng ngày có ý nghĩa / thứ tự không ổn định theo thời gian có thể là vấn đề đối với một ứng dụng. Và vì các thay đổi đối với quy tắc vùng là trường hợp cạnh, nên các vấn đề có thể xuất hiện vào thời điểm không mong muốn.

Một lý do thứ hai (có thể) cho lời khuyên là việc xây dựng một ZonedDateTimekhông rõ ràng ở những điểm nhất định. Ví dụ: trong khoảng thời gian khi bạn "đặt lại đồng hồ", kết hợp giờ địa phương và id vùng có thể cung cấp cho bạn hai mức bù khác nhau. Ý ZonedDateTimechí sẽ luôn chọn cái khác ... nhưng đây không phải luôn là lựa chọn chính xác.

Bây giờ, đây có thể là một vấn đề cho bất kỳ ứng dụng nào xây dựng ZonedDateTimecác giá trị theo cách đó. Nhưng từ quan điểm của một người nào đó xây dựng một ứng dụng doanh nghiệp là một vấn đề lớn hơn khi các ZonedDateTimegiá trị (có thể không chính xác) vẫn tồn tại và được sử dụng sau này.