Lấy múi giờ mysql
Trong bài viết trước, mình đã giới thiệu các bạn những khái niệm cơ bản liên quan đến ngày giờ & múi giờ. Bài viết này mình sẽ phân tích một số vấn đề thường gặp trong thực tế Show Trước tiên chúng ta sẽ ôn lại các khái niệm cơ bản
khoảng khăcLà một khoảng cụ thể có thể giải thích trong dòng lịch sử
Khi biểu diễn, cần có đủ hai thành phần. ngày giờ + ngữ cảnh nơi chốn. Ngữ cảnh ở đây chính là múi giờ (vùng). Các múi giờ được đặc trưng bởi một độ lệch thời gian (bù đắp) vì vậy với giờ phân phối quốc tế UTC. Độ lệch được biểu diễn dưới dạng
Trong máy tính, khoảnh khắc được biểu diễn dưới dạng Epoch Time - số giây trôi qua kể từ 00. 00. 00 ngày 1 tháng 1 năm 1970 theo giờ UTC thời gianThời gian chỉ mang tính hiển thị (thời gian đại diện, gọi tắt là rtime), không kèm theo múi giờ hay độ lệch, không dùng để đối chiếu so sánh
Khi thêm vùng hoặc bù vào thời gian, chúng ta sẽ có một lúc
Nếu chưa phân biệt được rtime/moment, bạn có thể xem lại bài viết trước 3 Common Unknown Error1. Bạn đã chọn đúng lớp để xử lý?Việc chọn nhầm kiểu dữ liệu có thể bắt nguồn từ sự nhầm lẫn giữa thời gian và thời điểm - bạn muốn xử lý thời gian ở dạng rtime nhưng chọn lại kiểu thời điểm và đảo ngược Chúng ta cùng xem lại danh sách các lớp ngày giờ trong Java tương ứng với 2 loại thời gian Type timeJava Classrtime(Java 1. 8)LocalDate , LocalTime , LocalDateTime khoảnh khắcjava.util.Date , 0(sql) 1, 2, 3(Java 1. 8) 4, 5, 6Loại thời gian rtime chỉ mới xuất hiện ở Java 1. 8 - vậy trước đó xử lý kiểu gì?
Để giải quyết vấn đề này, chúng ta phải hiểu bản chất của 7 - bản chất của nó là khoảnh khắc (hiển nhiên rồi, vì nó chứa Epoch Time), nhưng cũng có thể xem nó là rtime, do Java sẽ tự động chuyển đổi về múi giờ của nó.
Nhiều người hay nhầm lẫn và không nắm được bản chất của 7, dẫn đến việc vô tình tạo ra lỗi khi hệ thống múi giờ bị thay đổiVới thiết kế của bộ DateTime mới, công việc xử lý thời gian sẽ trở nên chặt chẽ hơn bằng cách đưa ra hệ thống quy chiếu thời gian/thời điểm
2. Bạn đã chọn đúng lớp để lưu trữ?Cho dù đã phân biệt được 2 loại thời gian và chọn đúng lớp để thao tác, chúng ta vẫn có khả năng chọn nhầm kiểu lưu trữ bên dưới cơ sở dữ liệu Trong Java, chúng ta sử dụng JDBC - Java Database Connectivity - một API cho phép hệ thống tương tác với cơ sở dữ liệu. Dưới đây là bảng ánh xạ kiểu dữ liệu tổng hợp của JDBC (Nguồn Oracle) Java TypeJDBC Type_______39_______ 7 (chỉ dành cho Oracle) 8 (all other databases) 1 7 2 2 3 8
Thôi bình tĩnh nhé. Thực hiện nó. but compiles more than as so. Ứng dụng với từng Nhà cung cấp cơ sở dữ liệu (Postgres, MySQL. ), chúng ta phải tuân theo một kiểu ánh xạ khác nhau Mặc dù vậy, việc đưa ra hệ thống quy chiếu rtime/moment lại tương đối dễ dàng. Chúng ta xem xét 2 ví dụ về Postgres và MySQL postgres. DẤU THỜI GIAN hay DẤU THỜI GIAN?Postgres cung cấp 2 loại dấu thời gian là có múi giờ (TIMESTAMPZ) và không có múi giờ (TIMESTAMP). T liếc nhìn chúng ta sẽ cho rằng dấu thời gian luôn là khoảnh khắc. Tuy nhiên, Hướng dẫn Postgres giải thích
Như vậy đã rõ ràng, TIMESTAMP chính là rtime, còn TIMESTAMPZ chính là khoảnh khắc. Tài liệu của Trình điều khiển JDBC cho Postgres được đưa ra ánh xạ bảng như sau PostgreSQL™Java SE 8DATELocalDateTIMELocalTimeTIMESTAMPLocalDateTimeTIMESTAMPZOffsetDateTimeCó thể thấy, cách ánh xạ kiểu dữ liệu của Postgres hoàn toàn khớp với hệ thống quy chiếu rtime/moment ( The ta don't used 6 type to mapping TIMESTAMPZ, by 6 has contain logic processing Time Daylight Saving Time - while the chất lượng TIMESTAMPZ does not contain information as so that)
Như đã giải thích trước đó, chúng ta phải hiểu bản chất của 7
Đó là vì múi giờ của máy chủ phụ trợ và cơ sở dữ liệu ở các môi trường LOCAL, DEV và PROD luôn quán nhất với nhau. Vấn đề sẽ phát sinh nếu thay đổi múi giờ và phá vỡ sự quán nhất của hệ thống hiện tại Bạn có thể tự kiểm tra bằng cách lưu 7 xuống Postgres dưới dạng DẤU THỜI GIAN, sau đó thay đổi múi giờ của phụ trợ rồi đọc lại giá trị đó, chắc chắn sẽ có sự cốmysql. Ngày giờ hay Dấu thời gian?(Lưu ý là Dấu thời gian của MySQL và Postgres không giống nhau) Tài liệu của mô tả MySQL
Vì vậy, dễ dàng kết luận, DateTime chính là rtime, còn Timestamp là khoảnh khắc. Tuy nhiên, Trình điều khiển JDBC của MySQL là Trình kết nối/J có sự khác biệt so với Postgres. Để hiểu chính xác cách ánh xạ dữ liệu, bạn có thể tham khảo tài liệu của Connector/J Thêm nữa, giới hạn lưu trữ của Dấu thời gian trong MySQL là Thực hành tốt nhấtĐối với thời điểm hiện tại, chúng ta sẽ đi theo hướng dẫn của trình điều khiển JDBC mà chọn kiểu dữ liệu phù hợp (ở phụ trợ cũng như trong cơ sở dữ liệu) Đối với rtime (thời gian có tính năng lặp lại, ví dụ. time lock biểu tượng, lịch làm việc, ngày lễ kỷ niệm. ), if you don't cover datetime of Java 1. 8 thì tốt nhất nên lưu dạng string vì tính dễ đọc, dễ debug và không gây hiểu lầm. Chúng ta sẽ cần thêm vài bước trung gian để phân tích cú pháp và gắn zone/offset vào, tuy nhiên chuyện đó không tốn nhiều công sức. Nếu không sử dụng chuỗi, thì hãy đảm bảo tuân theo hướng dẫn từ nhà phát triển trình điều khiển JDBC 3. Bạn đang thiết kế giao diện đúng cách?Vâng, bạn không nghe nhầm đâu. Có phải bạn đã từng thấy một điều khiển chọn ngày giờ như thế này đúng không? (xdsoft. mạng - plugin jQuery) Tất nhiên rồi, đây là một biến thiết kế phổ biến, không có vấn đề gì với chiếc datetimepicker này cả Nhưng mình có một vấn đề. Giả sử chúng ta đang thiết kế một cuộc họp ứng dụng trực tuyến. Để chọn thời gian bắt đầu cuộc họp, chúng ta sử dụng datetimepicker như hình trên. Theo bạn, ngày giờ mà người dùng chọn có đáng tin cậy hay không? Câu trả lời. hên xui Phần lớn datetimepicker của thư viện sẽ trả về thời gian dựa trên múi giờ đang được cài đặt trên máy khách. Cố gắng đặt trường hợp người dùng đang sử dụng máy tính thuê của ai đó, với một khoảng thời gian khác. Lúc này bạn sẽ không biết thời gian mà người dùng chọn và gửi về từ frontend có đáng tin cậy hay không
Giải phápHướng giải quyết của chúng ta rất đơn giản - hãy tham khảo giải pháp của những "ông lớn" Màn hình tạo cuộc họp của Outlook Màn hình tạo sự kiện của Facebook Chúng ta thấy, hệ thống của Outlook phục vụ cho người dùng của toàn cầu, làm việc đó bổ sung vào lựa chọn múi giờ cũng là chuyện dễ hiểu. Còn đối với Facebook, họ chỉ sử dụng loại truyền thống datetimepicker, nhưng kèm theo đó hiển thị rõ ràng giá trị thời gian mà người dùng chọn sẽ thuộc về múi giờ nào (múi giờ của máy tính họ đang sử dụng - như ví dụ trong GMT + Điểm chung của 2 hướng tiếp giáp này chính là tính chất rõ ràng của thời gian - người dùng sẽ biết cách chọn đúng giá trị mà họ muốn Đối với những hệ thống chỉ dùng ở một địa phương hoặc một quốc gia, tốt nhất nên theo hướng tiếp cận như Facebook (hiển thị rõ múi giờ cho người dùng), để tránh những hiểu nhầm không mong muốn |