homepage

There's an issue with email.utils.formatdate function, illustrated here: https://gist.github.com/1321994
for reference i'm on Europe/Istanbul timezone, which is +03:00 because of DST at the time of this writing.
I'm on stable Python 2.7.2 on gentoo linux. 
When I run the attached script, I get:
 2011年10月28日 07:56:14 -0000
 datetime.datetime(2011, 10, 28, 9, 56, 14, 945831, tzinfo=<UTC>)
when the local time is 12:56. so the second line is correct and first one is not.
let me know if you need any more information.
thanks for your attention.

turns out timetuple was not passing timezone information. the correct way of converting a datetime.datetime object to a correct rfc-2822 compliant date string seems to be:
email.utils.formatdate(time.mktime(a.utctimetuple()) + 1e-6 * a.microsecond - time.timezone)
what a mess. if the above is indeed the right way to do this, is it possible to add the following function to the email.utils module?
def formatdatetime(dt_object):
 return email.utils.formatdate(time.mktime(dt_object.utctimetuple()) + 1e-6 * a.microsecond - time.timezone)
this works for datetime instances both with and without time zone information.
ps: i updated the code in the github link but not here.

I have strange behavior too:
im@cgt-serv ~ $ python
Python 2.6.6 (r266:84292, Feb 28 2011, 09:01:15)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.Utils import formatdate
>>> import time
>>> time.strftime("%a, %d %b %Y %T %z")
'Wed, 02 Nov 2011 18:21:08 +0400'
>>> formatdate(localtime=True)
'Wed, 02 Nov 2011 18:21:28 +0300'
>>>

We have the same issue in Russia (MSK timezone). It seems to be related to recent changes in timezone info.
It looks like time.timezone is calculated incorrectly.
You can test that with attached script:
$ TZ=Europe/Moscow python /tmp/test_tz.py
-10800 -14400
Both values should be the same.

Perhaps it's better to calculate utc-offset for each timestamp cause we never know what is correct timezone for given time.
That could be done in C:
localtime, utc_offset = time.localtime_ex(t)
Where localtime is the same as returned by localtime() and utc_offset is set to tm.tm_gmtoff.
If tm_gmtoff isn't available on the target platform time.timezone or time.altzone will be used depending on time.daylight.
Here is simple python version, that subtracts gmtime from localtime tuple:
import time
def calculate_utc_offset(t):
 """
 Returns localtime offset for given unix-time `t`
 """
 loco = time.localtime(t)
 utc = time.gmtime(t)
 odd = cmp(loco.tm_year, utc.tm_year) or cmp(loco.tm_yday, utc.tm_yday)
 return (1440 * odd +
 60 * (loco.tm_hour - utc.tm_hour) +
 loco.tm_min - utc.tm_min))

Unless I misunderstand your concerns, this is a duplicate of issue 665194.

I'm not quite sure. The problem is email.utils.formatdate doesn't respect TZ info changes since it uses time.timezone (or time.altzone) for utc offset. 
Btw it seems that issue 665194 should fix the problem.

formatdate doesn't know anything about datetimes, so it doesn't make any sense to me to say that it doesn't notice changes in tzinfo. That's why the fix for issue 665194 introduces a new method for formatting datetimes.