Some friends of mine use Incredimail as their e-Mail client. Everytime when I receive an email from them, this e-Mail is shown with Date 01.01.1970 01:00 and sorted in Group By Sort under "Yesterday". Screenshot: http://www.grasschnixe.de/meri/Group_by_Sort.gif In M$ Outlook 2003 and Outlook XP, mails are always shown correctly. On IMAP and POP3. This problem appears only, when i receive emails with TB and were sent by incredimail. The Date in the header of the GMX Mail watched with TB 0.8, 0.9 and 1.0 is: Date: =?iso-8859-1?B?TW9uLCAyMiBOb3YgMjAwNCAxNzo1OTo1MCArMDEwMCAoV2VzdGV1cm9w5GlzY2hlIE5vcm1hbHplaXQp?= As I watched the Header in my GMX Webinterface, it looked normal: Date: Mon, 22 Nov 2004 17:59:50 +0100 (Westeuropäische Normalzeit) And on my Unisurf Account (The same email sent to GMX and Unisurf at the same time) it is that: Date: Mon, 22 Nov 2004 18:00:01 +0100 (Westeuropäische Normalzeit) The funny thing is, when I open this email and watch the header, Date is correct, in both emails. So it seems, as if the Viewpane-Code has a Bug

I set up a message in my mail with the date string supplied by reporter. In Thunderbird 1.0, Win2K: The date in the date column is incorrect, I see 31-Dec-69 06:00pm (I'm in the CDT (-0600) timezone) But the date in the Envelope panel is correctly shown as 22-Nov-04, 10:59am In Mozilla 1.8a6-1217, Win2K: The date in the date column is shown with the same incorrect value But the date in the Envelope panel is also incorrectly displayed -- and *differently* displayed every time I select the message. Here are some samples: 21-Sep-63 09:20 pm 28-Aug-17 11:20 am 10-Oct-34 10:28 pm 19-Apr-23 09:26 am

*** Bug 279818 has been marked as a duplicate of this bug. ***

(In reply to comment #1) RFC2047 says : ( http://www.faqs.org/rfcs/rfc2047.html ) > 6. Support of 'encoded-word's by mail readers > 6.1. Recognition of 'encoded-word's in message headers (snip) > 'encoded-word's are to be recognized as follows: > (1) Any message or body part header field defined as '*text', or any > user-defined header field, should be parsed as follows: (snip) > (2) Any header field not defined as '*text' should be parsed > according to the syntax rules for that header field. However, > any 'word' that appears within a 'phrase' should be treated as an > 'encoded-word' if it meets the syntax rules in section 2. > Otherwise it should be treated as an ordinary 'word'. I think that RFC2822's definition of each field of Date: header is NOT "*text", NOT "phrase", NOT "word", although used characters in each field is subset of characters used for "atext", "ctext", "phrase" or "word". - For example, day-name = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" (See http://www.faqs.org/rfcs/rfc2822.html for other fields) Then I think RFC2047 6.1 (2) should be applied to Date: header. ie. Encoding of Date: header field(s) to "encoded-word"(s) is violation of RFC2047 and RFC2822. Mike, what do you think?

Correction of my comment #3. - 'comment' field in Date: header (last "( comment-text-string )" part) can be 'encoded-word' becaue next is CFWS definition. CFWS = *([FWS] comment) (([FWS] comment) / FWS) comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment ctext = NO-WS-CTL / ; Non white space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-126 ; ")", or "\" Another RFC2047 violation in comment #0 case. RFC2047 "2. Syntax of encoded-words" section says: > An 'encoded-word' may not be more than 75 characters long, including > 'charset', 'encoding', 'encoded-text', and delimiters. If it is > desirable to encode more text than will fit in an 'encoded-word' of > 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may > be used. > > While there is no limit to the length of a multiple-line header > field, each line of a header field that contains one or more > 'encoded-word's is limited to 76 characters. 'encoded-word' in Date: header of comment #0 is 97 bytes long.

(In reply to comment #3) > Mike, what do you think? I think you're right on both counts.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.