On Thu, Nov 08, 2001 at 02:23:58PM -0800, Dan Mick wrote:

...

...

So it looks like my options are to use asctime(gmtime(time)) or write a routine that parses time.timezone into "-0600".

Luckily 'altzone' is defined in time, so

"+%02d%02d" % (time.altzone / 3600, time.altzone % 3600)

Well, that's not totally right either. It doesn't look as though 'time' has a function to tell us if we're in the DST timezone or the non-DST timezone, so there's no way to tell if we're supposed to use 'timezone' or 'altzone'.

Well, there's the ninth return value of localtime(). But I'm too lazy to write the code to use it (as you can surely tell by the fact that I'm too lazy to tell the difference between altzone and timezone.. ;)

So it looks to me like using 'gmtime' is the only way to get the right info under all circumstances.

To be totally RFC 822/2822 compliant, you could convert to GMT (using gmtime) and then blindly append "+0000". But since (in 2.0.6) this only happens to messages on the way to being archived, it doesn't seem terribly likely that message will ever be resent again. So as long as the archiver is happy I'm not too concerned.

Ugh. I just noticed that RFC 2822 requires day-month-year-time order, while ctime and asctime produce month-day-time year order. So looks to me like this is most correct:

time.strftime("%a, %d %b %Y %H:%M:%S +0000", time.gmtime(time.time()))