[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-11-07 Thread R. David Murray
R. David Murray added the comment: 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. -- _

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-11-07 Thread Vitja Makarov
Vitja Makarov added the comment: 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. -- ___

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-11-07 Thread R. David Murray
R. David Murray added the comment: Unless I misunderstand your concerns, this is a duplicate of issue 665194. -- nosy: +r.david.murray resolution: -> duplicate status: open -> closed superseder: -> datetime-RFC2822 roundtripping ___ Python tracker

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-11-07 Thread Vitja Makarov
Vitja Makarov added the comment: 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_of

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-11-03 Thread Vitja Makarov
Vitja Makarov added the comment: 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

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-11-02 Thread Mikhail I. Izmestev
Mikhail I. Izmestev added the comment: 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 >>> tim

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-10-29 Thread Petri Lehtinen
Changes by Petri Lehtinen : -- nosy: +petri.lehtinen type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-10-28 Thread Burak Arslan
Burak Arslan added the comment: 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.timez

[issue13284] email.utils.formatdate function does not handle timezones correctly.

2011-10-28 Thread Burak Arslan
New submission from Burak Arslan : 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.