Andrew Stuart writes:
It seems like a good idea to me to normalise dates on emails to UTC but you guys would know best.
No, you don't touch any dates *on* the email. You parse them and convert to UTC for internal handling (whatever that might be).
What would be the pros and cons of email date normalisation to UTC? Are there good reasons not to?
The cons of touching the dates in the header: only the Date field format is standardized, although the trace fields (Received and some others) often use the same date format. However, each MTA formats those trace fields differently, and most are configurable to insert more or trace less information. Get the format wrong and the message looks forged. Also you'll break any signatures applied to those fields. (Most Mailman lists break those signatures anyway, but there's no point in doing that gratuitously.)
As Barry says, for internal use, converting to UTC (actually, to a datetime object) is the obvious thing to do. If you're actually going to do any comparisons, it's useful. Using a datetime object will preserve timezone information.
Which date field on an email is even the right one to use?
All of them, but for different purposes.
Sent date or received date?
Some deadlines are postmarked by, others are received by. Sent vs. received depends on the application.
And WHICH received date , because there can be various dates can’t there?
Yes, there usually are multiple trace fields. Which to use depends on what you're using them for.