I’ve got a Plone instance that’s being run for users in Sydney, so the TZ environment variable is set to Australia/Sydney. With this set, code that uses the DateTime module from Zope2 produces results that display the wrong timezone. For instance:
>>> import time
>>> import DateTime
>>> print time.strftime("%a, %d %b %Y %T %z") #
Thu, 20 Sep 2012 02:38:08 +1000
>>> print DateTime.DateTime().rfc822()
Thu, 20 Sep 2012 02:38:08 -0400
This is rather problematic because Products.MailHost sets the Date: header on outgoing emails to the value DateTime().rfc822() (on line 466 of MailHost.py). Because the offset is wrong, the time in the Date header is now 12 hours into the future. SMTP servers receiving that email will often summarily reject it!
Other code in the same instance is quite happily behaving correctly with that TZ variable because it uses the datetime module in Python, which is all based on libc’s time.h functions.
So, what do people do in order to get the Plone’s MailHost to work in Australian time zones?
Unfortunately,
TZ=Australia/Sydneybecomestime.tzname == ('EST', 'EST'):And the DateTime internal database translates that to
US/Eastern. It is an unfortunate side-effect of Eastern Standard Time being the name for more than one timezone.You’d need to specify a more explicit
TZvariable specifying the offsets and the DST switch dates, with a new timezone name that won’t be misinterpreted:The above value comes from the still open bug report and happens to be perfect for your purposes:
You can add the
TZenvironment variable to your Zope configuration by sepecifying it in the buildout: