Bugs item #660733, was opened at 2003-01-01 09:29 Message generated for change (Comment added) made by cem You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=660733&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 7 Submitted By: Bryan Fullerton (fehwalker) Assigned to: Nobody/Anonymous (nobody) Summary: pipermail date handling Initial Comment: I moved my first list to mailman 2.1 and tried to re-generate the pipermail archives (just, ya know, to see how it'd work :), and got the following traceback. This is a list that's been around for a long time (archives back to 1995), and the .mbox file was generated from a majordomo/hypermail archive when it was moved to mailman 2.0 a couple of years ago. Here's a ls -l of the .mbox file: -rw-rw-r-- 1 mailman mailman 17741891 Jan 1 10:36 bryans-list.mbox Here's the traceback: Updating HTML for article 467 Updating HTML for article 468 Updating HTML for article 469 Updating HTML for article 473 Updating HTML for article 472 Pickling archive state into /home/mailman-2.1/archives/private/bryans-list/pipermail.pck Traceback (most recent call last): File "bin/arch", line 187, in ? main() File "bin/arch", line 175, in main archiver.processUnixMailbox(fp, start, end) File "/home/mailman-2.1/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox m = mbox.next() File "/usr/local/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman-2.1/Mailman/Mailbox.py", line 79, in scrubber return mailbox.scrub(msg) File "/home/mailman-2.1/Mailman/Mailbox.py", line 99, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman-2.1/Mailman/Handlers/Scrubber.py", line 132, in process dir = calculate_attachments_dir(mlist, msg, msgdata) File "/home/mailman-2.1/Mailman/Handlers/Scrubber.py", line 93, in calculate_attachments_dir datedir = safe_strftime(fmt, now) File "/home/mailman-2.1/Mailman/Handlers/Scrubber.py", line 77, in safe_strftime return time.strftime(fmt, floatsecs) TypeError: argument must be 9-item sequence, not None I'm guessing it's a header problem in one of the messages, but I'm not sure what. Thanks, Bryan ---------------------------------------------------------------------- Comment By: Christine Moore (cem) Date: 2004-04-21 10:13 Message: Logged In: YES user_id=170050 Not being a python programmer I'm not sure how difficult it would be to do this. But would it be possible to code it so that it just uses the envelope date instead or maybe if it can't get validly formatted data for the date it uses currently it would use the envelope date? The majority of the email that the archives here are having this problem with have a valid envelope date on them. ---------------------------------------------------------------------- Comment By: Zoran Dzelajlija (followme) Date: 2003-12-31 07:31 Message: Logged In: YES user_id=106281 I can confirm this with 2.1.2. Is there a simple way to make arch guess dates better? I would settle for arch using the date of the previous message, but I don't know wher to start digging in the code. ---------------------------------------------------------------------- Comment By: Bryan Fullerton (fehwalker) Date: 2003-01-01 10:45 Message: Logged In: YES user_id=660772 After some investigation, the following (admittedly invalid) date headers cause tracebacks similar to the above. After reformatting them I'm able to generate the archive. Date: 25 Aug 95 18.00 Date: Thursday, 30 October 1997 3:02pm PT Date: Mon, 29 Nov 1999 Pacific Standard Time Note that these messages *didn't* cause bin/arch|pipermail in mailman 2.0.x to fail, though it probably didn't parse them properly. Perhaps trapping the error and/or skipping these messages might be more useful? It also appears that bin/arch is throwing all messages with dates it can't figure out (after the above were removed) into the current day. An example can be seen at http://lists.samurai.com/pipermail/bryans-list/2003-January/thread.html . I'm unsure if there's any way to better handle this, but just wanted to note it - I can create a separate bug report if it's important. Thanks, Bryan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=660733&group_id=103