Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should email "Date" header be sender's local time or UTC?

I'm writing a web-based email client in Python and a question has arisen about which time zone the "Date" header of an email should be represented as when sending.

RFC 2822 states in section 3.3 that:

The date and time-of-day SHOULD express local time.

This seems ambiguous to me; the question is the local time of who? The email server, or the sender? Naturally I'd assume the sender (who could be in any time zone, and can be changed in their account preferences). Further confusion arose when I looked Python's email.utils.formatdate function which seems to only offer two alternatives: UTC or local time (of the server). To me there doesn't appear to be any option of specifying an alternate timezone, or am I missing something?

Passing a timeval to formatdate using time.mktime(senders_tz_aware_now_datetime.timetuple()) results in a UTC date string, which feels wrong given what the RFC says above.

So which timezone should "Date" be, and does any standard function exist to create the appropriate date string?

like image 871
kuhnza Avatar asked May 07 '12 18:05

kuhnza


People also ask

Does the email time stamp show the time of the sender or the recipient?

So basically, emails time-stamp displays the time it was received and in accordance with the time-zone of receiver.


1 Answers

If you want to adhere to the RFC, pass localtime=True which returns a date string with the local time and the right time zone (assuming you have it set up correctly).

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

Without localtime=True you get a date string representing UTC time:

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

-0000 apparently indicates UTC, although the RFC specifically recommends using +0000. Not sure if this is a bug in email.utils.

Here's the relevant python documentation:

Optional localtime is a flag that when True, interprets timeval, and returns a date relative to the local timezone instead of UTC, properly taking daylight savings time into account. The default is False meaning UTC is used.

like image 101
spinlok Avatar answered Sep 19 '22 14:09

spinlok