mktime() like function to produce GMT?

[Guido van Rossum]

"Mark Nottingham" <mnot at pobox.com> writes:

> Guido: I had tried a similar approach;
> 
> date = mktime(rfc822.parsedate(datestring)) - time.timezone
> 
> Neither this or mktime_tz will work; both will sometimes return dates that
> are off by one hour, depending on dst. I think this is because I'm parsing
> dates that may fall at any arbitrary time in the past, when the machine
> doesn't (AFAIK) have perfect knowledge about dst.
> 
> Ultimately, I'm trying to parse a UTC datestring (HTTP Last-Modified header
> in one of the three accepted formats) into a rfc1123-format datestring (as
> well as a number to play with); the date should never have to even know
> about localtime (which is causing all of the problems, in this case). With
> either the above solution or mktime_tz(), some dates will parse back to
> themselves, while others will have a one hour offset.
> 
> One such date (in my tz - aust eastern) is "Tue, 18 Mar 1997 05:32:18 GMT"
> which, after munging, will think it's 04:32:18.
> 
> I'm testing with:
> 
> #!/usr/bin/env python
> import sys, time, rfc822
> g = list(rfc822.parsedate_tz(sys.argv[1]))
> g[9] = 0
> date = rfc822.mktime_tz(tuple(g))
> print time.strftime('%a, %d %b %Y %H:%M:%S GMT', time.gmtime(date))

Hmm...  For me, in the US Eastern timezone, with Python 1.5.2, this
works.  It's been a long time but I really believe that the theory of
mktime predicts that it *should* work -- if you tell it not to use
daylight savings time it shouldn't.

Which Python version are you using?  (There has been some weirdness in
previous versions.)  What Unix platform?  It's sometimes hard to get
time.timezone to be the right value (very convoluted code in
timemodule.c, which has changed again in 1.5.2).  Could it that
there's a bug there because your DST is on the other half of the year?

--Guido van Rossum (home page: http://www.python.org/~guido/)