[Mailman-Developers] clobber_date bug

[Dan Mick]

> 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()))