2013-08-07 44 views
5

Tôi cần phải chuyển đổi một số trường TIMESTAMP thành INT trong MySQL (InnoDB) DB của chúng tôi. Tôi nhận ra rằng việc chuyển đổi TIMESTAMP thành INT là không bình thường, nhưng chúng tôi vẫn cần phải làm điều đó :)Mysql chuyển đổi TIMESTAMP thành INTEGER - múi giờ

Có vẻ như đủ để làm, nhưng có một số lỗi tiết kiệm múi giờ và ánh sáng ban ngày.

Tôi có tập lệnh tạo mã SQL cho mỗi cột. Ví dụ, nó tạo ra:

ALTER TABLE alarmLog ADD COLUMN started_tmp INT UNSIGNED; 
UPDATE alarmLog SET started_tmp = UNIX_TIMESTAMP(started); 
ALTER TABLE alarmLog DROP started; 
alter TABLE alarmLog CHANGE started_tmp started INT UNSIGNED NULL DEFAULT 0; 

Nếu tôi so sánh trước và sau khi sử dụng dữ liệu select FROM_UNIXTIME(1291788036);, kết quả có vẻ tốt.

Ý tưởng là sau đó thay đổi tất cả phần mềm phía máy khách để chuyển thành UTC và sử dụng INT đó khi lưu trữ. Khi truy xuất, INT đó được chuyển đổi thành múi giờ hiện tại.

Nhưng sau đó các tài liệu warn me về kịch bản này (tiết kiệm ánh sáng ban ngày trong giờ CET):

mysql> SELECT UNIX_TIMESTAMP('2005-03-27 02:00:00'); 
+---------------------------------------+ 
| UNIX_TIMESTAMP('2005-03-27 02:00:00') | 
+---------------------------------------+ 
|       1111885200 | 
+---------------------------------------+ 
1 row in set (0.00 sec) 

mysql> SELECT UNIX_TIMESTAMP('2005-03-27 03:00:00'); 
+---------------------------------------+ 
| UNIX_TIMESTAMP('2005-03-27 03:00:00') | 
+---------------------------------------+ 
|       1111885200 | 
+---------------------------------------+ 
1 row in set (0.00 sec) 

Làm thế nào để API và hệ điều hành bình thường đối phó với tiết kiệm ánh sáng ban ngày? Tôi biết máy tính của tôi có đồng hồ của nó trong UTC và trong thời gian mùa hè, hệ điều hành thêm hai giờ vào nó, và trong một thời gian mùa đông. Tôi giả sử nó sử dụng thời gian UTC để xác định cho dù đó là DST hay không.

Vì vậy, làm cách nào để giải quyết vấn đề này? Là giải pháp duy nhất để thêm một trường vào cơ sở dữ liệu để chỉ định bù DST?

+1

Giờ mùa hè là múi giờ khác. Ví dụ. CET là Giờ Trung Âu, CEST là Giờ mùa hè Trung Âu. Hệ điều hành của bạn biết khi nào cần chuyển đổi. Miễn là bạn sử dụng UTC cho dấu thời gian, nó là đến lớp trình bày để chuyển đổi đó vào thời gian địa phương. –

Trả lời

3

Bạn không cần phải lưu trữ thời gian trong INT's. Kiểu TIMESTAMP của MySQL thực hiện điều đó (nó sử dụng dấu thời gian unix tiêu chuẩn để lưu trữ thời gian) và chúng luôn ở dạng UTC.

Bạn chỉ cần đặt múi giờ phiên và tất cả cột TIMESTAMP sẽ được chuyển đổi từ/sang vùng của bạn khi bạn cập nhật/chọn chúng.

Bạn có thể thiết lập các khu ở kết nối thời gian/khởi tạo một lần:

SET time_zone = '+10:00'; 

Và sau đó bạn có thể chọn/cập nhật thời gian trong khu vực của bạn trực tiếp

SELECT timesamp_column FROM table ... 

Tôi không phải là rất quen thuộc với datetime libs nhưng tôi đoán họ sử dụng múi giờ mà bạn đã cung cấp và thời gian được đề cập để xác định chênh lệch múi giờ và tiết kiệm ban ngày.

Trong ví dụ bạn đã cung cấp, tôi nghĩ một trong các giá trị thực sự không hợp lệ, vì đồng hồ giả sử nhảy từ 01:59:59 đến 03:00:00 và 02:00:00 chưa bao giờ thực sự xảy ra. Hàm UNIX_TIMESTAMP có thể trả về giá trị thứ hai gần nhất trong trường hợp đó.

+0

Tôi biết tôi có thể sử dụng dấu thời gian, nhưng tôi không thể sử dụng loại đó. Phía máy khách cần tương thích với sqlite, do đó chuyển đổi thành INT. Và về thời gian không hợp lệ; vào cuối ánh sáng ban ngày, bạn tiết kiệm một thời gian nhất định hai lần một ngày, mà sẽ có cùng một vấn đề. – Halfgaar

+0

Có nhiều điểm đúng lúc với cùng biểu diễn chuỗi và cũng có những khoảng trống. Tôi không nghĩ có bất cứ điều gì bạn có thể làm về điều đó. Lưu trữ các giá trị của bạn dưới dạng dấu thời gian (INT) và chuyển đổi chúng thành giờ cục bộ với các hàm của MySQL hoặc phía máy khách thư viện thời gian. Miễn là bạn đã đặt múi giờ chính xác, nó sẽ hiển thị chính xác. – Vatev

+0

Tôi vừa thử nghiệm chèn '2005-03-27 02:00:00' trong cột TIMESTAMP. Lấy nó cũng cung cấp cho bạn '2005-03-27 03:00:00', vì vậy tôi đoán nó là tốt. – Halfgaar