Múi giờ có thời gian tiết kiệm ánh sáng ban ngày trong PostgreSQL

Question

Chúng tôi đang triển khai các đồng hồ đo dòng riêng của mình (rất giống với thước đo USGS này: http://waterdata.usgs.gov/usa/nwis/uv?site_no=03539600) để chúng tôi biết có đủ nước để chèo xuồng và không lãng phí thời gian và gas để lái xe ra khỏi đó. Chúng tôi hy vọng cài đặt một vài trong số này trên khu vực whitewater phía đông nam kéo dài các múi giờ phía đông và trung tâm.

Tôi đang lưu trữ thời gian bản ghi được chèn bằng giá trị mặc định của current_time cho bản ghi. Tôi muốn hiển thị dữ liệu sau bằng cách sử dụng định dạng MM/DD/YYYY HH12:MI AM TZ, định dạng này sẽ xuất ra dạng đọc như 03/12/2012 01:00 AM CDT. Tôi cũng muốn cho đầu ra nhận thức được những thay đổi trong thời gian tiết kiệm ánh sáng ban ngày, vì vậy phần cuối của câu trước sẽ thay đổi giữa CST và CDT khi chúng ta 'tiến lên' và 'lùi lại'. Thay đổi này xảy ra vào ngày 11 tháng 11 năm 2012 và tôi đã bao gồm các ngày ở cả hai bên của dòng DST này bên dưới. Tôi đang sử dụng máy tính xách tay Windows 7 để phát triển và sau này chúng tôi sẽ triển khai trên một hộp Unix. Postgres dường như đã phát hiện ra rằng máy tính Windows của tôi được đặt ở múi giờ miền đông Hoa Kỳ. Tôi đang thử điều này với trường 'dấu thời gian không có múi giờ' và trường 'dấu thời gian có múi giờ' nhưng không thể làm cho nó hoạt động.

Tôi đã thử sử dụng 'tại múi giờ' trong các lựa chọn của mình và mọi thứ đều hoạt động cho đến khi đến lúc hiển thị múi giờ. Giờ thực tế là một phần của tem thời gian được trừ một cách chính xác bởi một giờ khi tôi yêu cầu thời gian trong CDT. Nhưng EDT được hiển thị ở đầu ra.

SELECT reading_time as raw, 
     reading_time at time zone 'CDT', 
     to_char(reading_time at time zone 'CDT', 
      'MM/DD/YYYY HH12:MI AM TZ') as formatted_time 
    FROM readings2; 

"2012-04-29 17:59:35.65";"2012-04-29 18:59:35.65-04";"04/29/2012 06:59 PM EDT" 
"2012-04-29 17:59:40.19";"2012-04-29 18:59:40.19-04";"04/29/2012 06:59 PM EDT" 
"2012-03-10 00:00:00";"2012-03-10 00:00:00-05";"03/10/2012 12:00 AM EST" 
"2012-03-11 00:00:00";"2012-03-11 00:00:00-05";"03/11/2012 12:00 AM EST" 
"2012-03-12 00:00:00";"2012-03-12 01:00:00-04";"03/12/2012 01:00 AM EDT" 

Tôi đang lưu trữ múi giờ mà mỗi đồng hồ đo của chúng tôi nằm trong trường biến đổi ký tự một bảng riêng biệt. Tôi xem xét chỉ cần thêm giá trị này vào cuối thời gian đầu ra, nhưng tôi muốn nó thay đổi từ từ CST sang CDT mà không có sự can thiệp của tôi.

Cảm ơn sự giúp đỡ của bạn.

Answer 1

Thay vì sử dụng các tên múi giờ như CDT hoặc CST, bạn có thể xem xét sử dụng full Olsen-style time zone names. Trong trường hợp thời gian trung tâm, bạn có thể chọn múi giờ. Một địa chỉ khớp với vị trí của bạn, chẳng hạn như America/Chicago hoặc chỉ US/Central. Điều này đảm bảo PostgreSQL sử dụng cơ sở dữ liệu Olsen tz để tự động tìm ra liệu thời gian tiết kiệm ánh sáng ban ngày có áp dụng tại bất kỳ ngày cụ thể nào không.

Answer 2

Bạn chắc chắn muốn một cột TIMESTAMP WITH TIME ZONE (còn được gọi là timestamptz trong PostgreSQL). Điều đó sẽ lưu dấu thời gian trong UTC, để nó biểu thị một thời điểm cụ thể trong thời gian. Trái với những gì tên cho thấy, nó không lưu múi giờ trong cột - bạn có thể xem dấu thời gian đã truy xuất trong múi giờ bạn chọn với cụm từ AT TIME ZONE.

Ngữ nghĩa của TIMESTAMP KHÔNG CÓ Múi giờ khó hiểu và gần như vô dụng. Tôi khuyên bạn không nên sử dụng loại đó cho tất cả những gì bạn mô tả.

Tôi thực sự bối rối bởi một phần của câu hỏi nói về lưu trữ dấu thời gian trong cột CHARACTER VARYING. Điều đó có vẻ như nó có thể là một phần của vấn đề. Nếu bạn có thể lưu trữ nó trong timestamptz ngay từ đầu tôi nghi ngờ rằng bạn sẽ có ít vấn đề hơn. Chặn rằng, nó sẽ là an toàn nhất để sử dụng ký hiệu -04 cho bù đắp từ UTC; nhưng điều đó có vẻ như làm việc nhiều hơn cho tôi vì không có lợi ích gì.

Answer 3

Bạn có thể tạo bảng thời gian đã biết theo định dạng được đề xuất trong Guan Yang's answer và sau đó sử dụng cột khóa ngoài cho bảng này. Bạn có thể lấy múi giờ hợp lệ từ pg_timezone_names Tôi đã đi vào chi tiết hơn trong this related answer.