Cách xử lý múi giờ MySQL trong script

Bạn đã chạy truy vấn chẩn đoán thời gian này trên máy chủ MySQL của mình.

select @@time_zone, now(), utc_timestamp()

Theo giờ địa phương và giờ tối đa của bạn, cài đặt múi giờ hệ thống của máy chủ của bạn là 'Canada / Mountain' và phần mềm máy chủ MySQL không có cài đặt múi giờ riêng.

Nếu bạn chọn bảng của mình và chuyển chúng không thay đổi đến máy chủ ở một số múi giờ gần đó, bạn có thể cập nhật phần mềm của mình luôn để đưa ra lệnh

set time_zone = 'Canada/Mountain';

ngay sau khi bạn kết nối từ phần mềm của mình. Điều này sẽ làm cho kết nối MySQL mới của bạn hoạt động giống như kết nối hiện tại của bạn theo múi giờ. Nếu bạn sở hữu máy chủ MySQL, bạn có thể đặt múi giờ mặc định của nó theo hướng dẫn trên trang này. http://dev.mysql.com/doc /refman/5.5/en/time-zone-support.html

Bây giờ, đây là câu chuyện về các loại dữ liệu thời gian. DATE , TIME và DATETIME tất cả đều không biết múi giờ . Khi bạn đã lưu trữ giá trị ngày / giờ, bạn sẽ nhận lại giá trị đó ngay cả khi bạn thay đổi cài đặt múi giờ của mình.

TIMESTAMP loại dữ liệu phân biệt múi giờ . Các mục dữ liệu đó luôn được lưu trữ trong UTC, còn được gọi là Z, time , trước đây được gọi là Giờ trung bình Greenwich. Chúng luôn được chuyển đổi thành UTC khi được lưu trữ và luôn được chuyển đổi trở lại khi được truy xuất.

các hàm nội trang để nhận ngày và giờ hiện tại (NOW() và bạn bè) có phân biệt múi giờ . Họ sẽ mang lại giá trị theo giờ địa phương. Các ngoại lệ là ba hàm bắt đầu bằng UTC_ mang lại giá trị theo giờ UTC.

Nhiều ứng dụng MySQL đa múi giờ sử dụng nguyên tắc hoạt động sau:

1. Hỏi từng người dùng về múi giờ tùy chọn của người dùng hoặc tìm ra múi giờ đó từ một số dữ liệu cá nhân khác về người dùng. (Điện thoại có thông tin này được cung cấp từ mạng.) Lưu trữ thông tin đó dưới dạng zoneinfo-thân thiện bộ mô tả múi giờ ('America / New_York', 'Canada / Mountain', 'Europe / Vienna', v.v.) thay mặt người dùng.
2. Sau khi thiết lập phiên MySQL thay mặt cho người dùng, hãy đặt múi giờ của người dùng bằng set time_zone truy vấn giống như một trong những hiển thị ở trên. Bạn nên thực hiện việc này ngay sau khi connect hoạt động.
3. Lưu trữ ngày và giờ cho người dùng vào TIMESTAMP Loại dữ liệu. Chúng sẽ được chuyển đổi sang UTC khi chúng được lưu trữ.
4. Truy xuất chúng khi cần thiết. Chúng sẽ được chuyển đổi trở lại giờ địa phương.

Ý tưởng là múi giờ của người dùng của bạn là một phần trong ngữ cảnh của cô ấy. Điều này hoạt động tốt, bởi vì nếu người dùng A ở Vancouver và người dùng B ở Halifax và vì lý do nào đó mà người dùng B xem dữ liệu thời gian của người dùng A, dữ liệu đó sẽ tự động được hiển thị cho B theo giờ Đại Tây Dương.

Nó cũng tốt vì nó xử lý minh bạch với sự thay đổi thời gian từ ánh sáng ban ngày sang thời gian tiêu chuẩn trên toàn cầu. Dấu thời gian từ mùa hè năm ngoái sẽ được hiển thị theo giờ địa phương của mùa hè năm ngoái.

Nhiều người quản lý máy chủ để sử dụng toàn cầu đã đặt thời gian máy chủ hệ thống hoặc múi giờ mặc định MySQL của họ thành UTC. (Của bạn thì không.)

Một cách khác để xử lý tất cả những điều này là cách bạn đã bắt đầu. Chọn một múi giờ và lưu trữ dấu thời gian của bạn đối với múi giờ đó. Tốt nhất là bạn nên chọn múi giờ không thay đổi giữa ánh sáng ban ngày và giờ chuẩn trong trường hợp đó. Sau đó, khi lưu trữ thời gian vào cơ sở dữ liệu, hãy chuyển đổi tính rõ ràng. Bạn có thể lưu trữ thời gian từ người dùng ở Ottawa bằng cách làm như thế này.

INSERT INTO tbl (appt) VALUES ( 'whatever-time' - INTERVAL 120 MINUTE)

và bạn sẽ nhận được các giá trị theo cùng một cách. Điều này dễ xảy ra lỗi nhưng bạn có thể làm cho nó hoạt động.

Cuối cùng, bạn có thể tự thực hiện chuyển đổi của mình. Nếu bạn muốn biết có bao nhiêu phút bù trừ giữa một số múi giờ trọng tài và UTC, hãy thử hai truy vấn sau.

set time_zone = 'Canada/Atlantic';
select timestampdiff(minute, utc_timestamp(), now());

Tại thời điểm này trong năm trả lại -240, tức là -4:00. Bạn cần sử dụng phút thay vì sử dụng giờ vì múi giờ chênh lệch nửa giờ hoặc một phần tư giờ ở một số quốc gia.

Cuối cùng, hãy coi chừng. TIMESTAMP kiểu dữ liệu không đại diện cho thời gian trước năm 1970. Và, trên phiên bản MariaDB 10.0 của tôi, nó dường như biến thành địa ngục ngay sau 2038-01-19T03:14:07 UTC khi thời gian trôi qua 32 bit.