Có nên gửi tiêu đề "Ngày" qua email là giờ địa phương hoặc UTC của người gửi không?

Question

Tôi đang viết một ứng dụng email dựa trên web bằng Python và một câu hỏi đã phát sinh về múi giờ của tiêu đề "Ngày" của một email sẽ được thể hiện như khi gửi.

RFC 2822 bang trong phần 3.3 rằng:

Ngày và thời gian của ngày NÊN hiện giờ địa phương.

Điều này dường như không rõ ràng đối với tôi; câu hỏi là giờ địa phương của ai? Máy chủ email hoặc người gửi? Đương nhiên tôi sẽ giả định người gửi (có thể ở bất kỳ múi giờ nào và có thể thay đổi tùy chọn tài khoản của họ). Sự nhầm lẫn hơn nữa nảy sinh khi tôi xem chức năng email.utils.formatdate của Python có vẻ như chỉ cung cấp hai lựa chọn thay thế: UTC hoặc giờ địa phương (của máy chủ). Đối với tôi, dường như không có bất kỳ tùy chọn nào để chỉ định múi giờ thay thế, hoặc tôi có thiếu gì đó không?

Chuyển thời gian định dạng bằng cách sử dụng time.mktime(senders_tz_aware_now_datetime.timetuple()) kết quả theo chuỗi ngày UTC, điều này cảm thấy sai về những gì RFC đã nói ở trên.

Vậy múi giờ nào sẽ là "Ngày" và có tồn tại bất kỳ hàm chuẩn nào để tạo chuỗi ngày thích hợp không?

Answer 1

Chỉ cần sử dụng UTC và bạn sẽ hạnh phúc hơn.

Đó là những gì đang xảy ra khi thông số kỹ thuật đang sử dụng các cụm từ như NÊN. Tôi nghĩ rằng cả hai NÊN có thể bị cấm từ thông số kỹ thuật bởi vì họ luôn tạo ra sự phức tạp không cần thiết.

Sử dụng UTC là hoàn toàn hợp lệ.

Answer 2

Nếu bạn muốn tuân thủ RFC, hãy vượt qua localtime=True trả về chuỗi ngày có múi giờ địa phương và múi giờ phù hợp (giả sử bạn đã thiết lập chính xác).

>>> email.utils.formatdate(localtime=True) 
'Mon, 07 May 2012 12:09:16 -0700' 

Without localtime=True bạn nhận được một chuỗi ngày đại diện cho thời gian tính theo giờ UTC:

>>> email.utils.formatdate() 
'Mon, 07 May 2012 19:08:55 -0000' 

-0000 rõ ràng chỉ ra UTC, mặc dù RFC đặc biệt khuyến cáo sử dụng +0000. Không chắc chắn nếu đây là một lỗi trong email.utils.

Dưới đây là tài liệu python liên quan:

Tùy chọn localtime là một lá cờ mà khi Đúng vậy, giải thích timeval, và trả về một ngày so với múi giờ địa phương thay vì tính theo giờ UTC, lấy đúng thời gian tiết kiệm ánh sáng ban ngày vào tài khoản. Mặc định là False nghĩa là UTC được sử dụng.

Answer 3

Điều này xuất hiện dưới dạng kết quả hàng đầu khi googling "thời gian địa phương của ứng dụng email khách"; Thật không may, hai câu trả lời và ý kiến ​​đi kèm hầu như không giải quyết việc thực hiện python, và thất bại hoàn toàn để nói chuyện với dòng chủ đề (đó là những gì ăn phản ứng google).

RFC rõ ràng vì rõ ràng: tiêu đề "^ Ngày:" là địa phương tại thời điểm được viết. Ứng dụng thư khách thường viết tiêu đề "^ Ngày:" (trong bất kỳ triển khai nào mà tôi đã xử lý). Đối với hầu hết các khách hàng (được cấu hình một cách an toàn), đây sẽ là giờ địa phương được báo cáo bởi hệ điều hành của khách hàng.

Trong trường hợp webmail, thời gian cục bộ có thể được cung cấp bởi tác nhân người dùng (lần này thường có thời gian cục bộ từ hệ điều hành). Thông thường nó sẽ được thiết lập bởi người dùng trong ứng dụng web (a la gmail).

Quan trọng, nếu bạn "theo RFC" (có thể là một ý tưởng tốt cho giao thức mạng), hành vi kết quả trên RECEIVING khách hàng nói chung sẽ hiển thị ngày thư được gửi bởi người gửi. Đây là toàn bộ điểm "NÊN" trong RFC. Tôi không muốn nhìn thấy UTC khi cố gắng tìm ra thời gian mà một đồng nghiệp đã gửi một email; Tôi muốn giờ địa phương của họ. Bằng cách đó, tôi có thể tìm ra sự khác biệt thời gian trong một bước (thời gian địa phương của họ để khai thác), không phải hai (thời gian địa phương của họ để UTC đến giờ địa phương của tôi). Tôi cũng nhận được những manh mối ngay lập tức về bối cảnh giao tiếp của họ (đó là đêm? Giờ làm việc? Vv).