Summary | Dates from old IMP versions not parsed correctly in inbox |
Queue | IMP |
Queue Version | 4.0.1 |
Type | Bug |
State | Not A Bug |
Priority | 2. Medium |
Owners | |
Requester | cfs (at) nova (dot) es |
Created | 01/16/2005 (7555 days ago) |
Due | |
Updated | 01/26/2005 (7545 days ago) |
Assigned | 01/16/2005 (7555 days ago) |
Resolved | 01/26/2005 (7545 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Not A Bug
own strtotime implementation or uses one from the system's libraries.
We can't do anything about this anyway. If the IMP2 installation that
sends these date headers is yours, change it to not include the
timezone.
Examples:
Tue, 25 Jan 2005 18:00:06 -0500 (EST) - displays "Unknown Date"
Tue, 25 Jan 2005 16:18:41 -0500 (Eastern Standard Time) - displays
"Unknown Date"
This displays correctly:
Tue, 25 Jan 2005 18:00:06 -0500
PHP 4.3.10
correctly in the inbox in both.
New Attachment: dates_bug.zip
original Qmail (Maildir) file.
I fixed the problem myself by adding a few lines in mailbox.php that
remove the last word in the date line if the word is all chars (which
would be it's a timezone). Probably a bad idea (Ithat's why I'm not
bothering with a patch) but will do for me for a few days.
State ⇒ Feedback
problem (a .eml file).
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Dates from old IMP versions not parsed correctly in inbox
Queue ⇒ IMP
timezone, such as
Sun, 16 Jan 2005 18:06:55 +0100 CET
these dates show as "Unknown date" in the folder view (they are
correctly parsed in the message view, though).
I've looked into this a bit, and the problem is that
strtotime($h->date, $curr_time) (for $h->date = any date with the
format shown above) returns -1. I'm using PHP 5.0.3.