RFC 2822 (which is the currently valid one, if I understand correctly) specifies the date format to have four digit zone specifications, ie "GMT+0200", while DateTime.rfc822() happily returns "GMT+2". Not that this seems to be any problem, I'm just looking for an answer if this is how it's supposed to be? I discovered it, because Outlook Express handles RFC822 dates incorrectly and will display both the "Fri, 11 Oct 2002 13:47:03 GMT+0200" and "Date: Fri, 11 Oct 2002 13:47:03 GMT+2" as "2002-10-11 15:47". Obviously some programmer at Microsoft hasn't read the rfc properly. :-) "The date and time-of-day SHOULD express local time. The zone specifies the offset from Coordinated Universal Time (UTC, formerly referred to as "Greenwich Mean Time") that the date and time-of-day represent." While MS obviously thinks it represents GMT. Easy mistake to do, if you don't read the rfc... Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Hello Lennart, Friday, October 11, 2002, 2:00:03 PM, you wrote: LR> RFC 2822 (which is the currently valid one, if I understand correctly) LR> specifies the date format to have four digit zone specifications, ie LR> "GMT+0200", while DateTime.rfc822() happily returns "GMT+2". Not that this LR> seems to be any problem, I'm just looking for an answer if this is how it's LR> supposed to be? i can confirm that this is a bug in DateTime.rfc822(), and that rfc-conformant mailclients choke on it aswell.. i believe it has been reported to the lists before , and i believe i have also seen it in the collector.. (the collector seems to be down , but i found this request on google.. http://mail.python.org/pipermail/zope-collector-monitor/2002-May/000652.html ) Your concerns are valid. i usually solve it by use of a small script(python) somewhat resembling this : # params indate fmtstr = "%a, %d %b %Y %X +0200" return indate.strftime(fmtstr) -- Geir Bækholt geirh@funcom.com
From: "Geir Bækholt" <geirh@funcom.com>
i can confirm that this is a bug in DateTime.rfc822(), and that rfc-conformant mailclients choke on it aswell..
Oh, man, I've looked at DateTime now, and it's a mess... (ar at least, the timeone hadnling is). I'm seriously considering making rfc822() into this: def rfc822(self): """Return the date in RFC 822 format""" return '%s, %2.2d %s %d %2.2d:%2.2d:%2.2d %s' % ( self._aday,self._day,self._amon,self._year, self._hour,self._minute,self._nearsec,'-0000') That would return the RFC2822 format that explicitly specifies that there is no timezone information included... At least that would make it compliant. :-/ A better way would be storing the timzone offset internally in the DateTime object and using it, but there timezone handling is spread out all over the place, so I haven't really gotten a grip on it yet. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Lennart Regebro wrote:
From: "Geir Bækholt" <geirh@funcom.com>
i can confirm that this is a bug in DateTime.rfc822(), and that rfc-conformant mailclients choke on it aswell..
Oh, man, I've looked at DateTime now, and it's a mess... (ar at least, the timeone hadnling is). I'm seriously considering making rfc822() into this:
def rfc822(self): """Return the date in RFC 822 format""" return '%s, %2.2d %s %d %2.2d:%2.2d:%2.2d %s' % ( self._aday,self._day,self._amon,self._year, self._hour,self._minute,self._nearsec,'-0000')
That would return the RFC2822 format that explicitly specifies that there is no timezone information included... At least that would make it compliant. :-/
A better way would be storing the timzone offset internally in the DateTime object and using it, but there timezone handling is spread out all over the place, so I haven't really gotten a grip on it yet.
Zope3 already uses the experimental datetime from Python2.3. From a quick look it seems to handle timezones. Perhaps you can look there for some ideas or use it instead. HTH, __Janko
From: "Janko Hauser" <jh@comunit.de>
Zope3 already uses the experimental datetime from Python2.3. From a quick look it seems to handle timezones. Perhaps you can look there for some ideas or use it instead.
It seems too risky to use experimental features from a version of python that is ahead of the python version used by the rest of Zope 2.6. I've solved it like this: def _tzoffset2rfc822zone(seconds): return "%+03d%02d" % divmod( (-seconds/60), 60) def rfc822(self): """Return the date in RFC 822 format""" if self._tz == self._localzone0: #Use local standard time tzoffset = _tzoffset2rfc822zone(localzone) elif self._tz == self._localzone1: # Use local daylight saving time tzoffset = _tzoffset2rfc822zone(altzone) else: tzoffset = '-0000' # unknown time zone offset return '%s, %2.2d %s %d %2.2d:%2.2d:%2.2d %s' % ( self._aday,self._day,self._amon,self._year, self._hour,self._minute,self._nearsec,tzoffset) This will give you the correct timezone information in almost all cases. Only when rfc822() is called on a DateTime which is in another timezone than the server will '-0000' be used. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB
participants (3)
-
Geir Bækholt -
Janko Hauser -
Lennart Regebro