The new Alertengine sends email alerts where the Date header is in UTC instead of local time:
From nav@gullars.uit.no Tue Jun 16 10:05:14 2009 Date: Tue, 16 Jun 2009 08:05:40 -0000
Alertengine uses Django to send mail, and Django sets the Date header like this:
from email.Utils import formatdate, parseaddr, formataddr ... if 'date' not in header_names: msg['Date'] = formatdate()
Calling formatdate() without arguments returns a date in UTC. So Django disregards its own time zone setting here. I'm not sure if it's done on purpose, but anyway a workaround in Alertengine would be to set the Date header explicitly to some localtime value, perhaps with:
formatdate(localtime=True)
or even better, use a value based on the time zone in the Django config. (Not sure how to do that.)
On Wed, 17 Jun 2009 11:20:10 +0200 Ole Martin Bjorndalen olemb@cc.uit.no wrote:
Date: Tue, 16 Jun 2009 08:05:40 -0000
Alertengine uses Django to send mail, and Django sets the Date header like this:
from email.Utils import formatdate, parseaddr, formataddr ... if 'date' not in header_names: msg['Date'] = formatdate()
Calling formatdate() without arguments returns a date in UTC. So Django disregards its own time zone setting here.
According to RFC2822, a timezone specification of "-0000" means that the time is UTC, but that the generating host may be in a different local time zone.
This is not an error, per se; I would expect a good email client to know that "08:05:40 -0000" is actually the same as "10:05:40 +0200".
I'm not sure if it's done on purpose, but anyway a workaround in Alertengine would be to set the Date header explicitly to some localtime value, perhaps with:
formatdate(localtime=True)
or even better, use a value based on the time zone in the Django config. (Not sure how to do that.)
We've already had problems with Django's time zone configuration and the generation of timestamps. I'd rather just specify localtime=True to the formatdate call and let that be the end of it. If you were to submit such a patch, I would accept it.