318323 - Mail message date in the future

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[John T]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051122 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051122 SeaMonkey/1.5a

My mail settings are to show various information about messages including the date or time of messages. One source of messages is a Yahoo discussion group called peace_and_politics. I first noted the problem on or shortly before Oct. 27 and have been seeing it in Seamonkey nightlies ever since. The problem does not occur when fetching mail with Mozilla 1.7.12.

A test message that I sent just now (Nov. 30) at about 9 AM came back showing the date Dec. 3 and time 11:17 PM, though the actual message shows the time and date (9:03 AM (no date, implying today)).

The future dates appear to be getting written into the msf file, and when Mozilla 1.7.12 loads my Inbox index, it fixes the problem by doing an index recreation. When I fetch mail with a Seamonkey nightly, any messages from that specific group are shown with the wrong date.

The correct date is shown when the actual message is displayed. Seamonkey is reading that correctly, but gets it wrong when showing the message list and adding to the msf file.

Reproducible: Always

Steps to Reproduce:
1. Run a Seamonkey built after Oct 26 2005
2. Open the mail window.
3. Fetch POP3 mail including messages from the peace_and_politics Yahoo discussion group.
Actual Results:  
The messages in the message list are shown with dates about 3 days in the future.

Expected Results:  
The date and time of messages should be shown correctly, i.e, the date and time they were sent.

Here's a copy of the header of my test message:

From - Wed Nov 30 09:06:45 2005
X-Account-Key: account1
X-UIDL: 4273d69f0000db2a
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <sentto-10635172-8812-1133363147-jrt=[e-mail]>
Received: from n5a.bulk.scd.yahoo.com (n5a.bulk.scd.yahoo.com [66.94.237.39])
	by wlc2.securesites.net (8.13.1/8.12.6) with SMTP id jAUF5rcb040849
	for <[e-mail]>; Wed, 30 Nov 2005 15:05:53 GMT
	(envelope-from sentto-10635172-8812-1133363147-jrt=[e-mail])
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lima; d=yahoogroups.com;
	b=CrM4iDH4HsJbIN4k3lxD2jGXyq3ALPOjZ9X6dKNTAR2iVGlU7qWw/IsaPSqI56+f1oS4uoPKgtSLKdK/t9RYLYUoxVeM277a4+BkBFkF9lbx9jXhhfijbHRwrRsa88Jp;
Received: from [66.218.69.4] by n5.bullet.scd.yahoo.com with NNFMP; 30 Nov 2005 15:05:48 -0000
Received: from [66.218.66.33] by mailer4.bulk.scd.yahoo.com with NNFMP; 30 Nov 2005 15:05:47 -0000
X-Yahoo-Newman-Property: groups-email
X-Sender: [e-mail]
X-Apparently-To: [e-mail]
Received: (qmail 10978 invoked from network); 30 Nov 2005 15:05:46 -0000
Received: from unknown (66.218.66.218)
  by m27.grp.scd.yahoo.com with QMQP; 30 Nov 2005 15:05:46 -0000
Received: from unknown (HELO wlc2.securesites.net) (192.220.111.15)
  by mta3.grp.scd.yahoo.com with SMTP; 30 Nov 2005 15:05:46 -0000
Received: from [4.88.165.166] (dialup-4.88.165.166.Dial1.StLouis1.Level3.net [4.88.165.166])
	(authenticated bits=0)
	by wlc2.securesites.net (8.13.1/8.12.6) with ESMTP id jAUF3Dfu039739
	for <[e-mail]>; Wed, 30 Nov 2005 15:03:14 GMT
	(envelope-from [e-mail])
Message-ID: <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051122 SeaMonkey/1.5a
To: "[e-mail]" <[e-mail]>
X-Originating-IP: 192.220.111.15
X-eGroups-Msg-Info: 1:12:0:0
From: JohnT <[e-mail]>
X-Yahoo-Profile: allltaken
Sender: [e-mail]
MIME-Version: 1.0
Mailing-List: list [e-mail]; contact [e-mail]
Delivered-To: mailing list [e-mail]
List-Id: <peace_and_politics.yahoogroups.com>
Precedence: bulk
List-Unsubscribe: <mailto:[e-mail]>
Date: Wed, 30 Nov 2005 09:03:30 -0800
Subject: [peace_and_politics] test msg for debugging purposes
Reply-To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-ClamAV: clean
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on 
	wlc2.securesites.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=99.0 tests=AWL,BAYES_00,
	RCVD_IN_SORBS_WEB,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2
Status:

Comment 1

[John T]

Perhaps Moz 1.7.12 doesn't usually rebuild an existing msf file. It didn't today. I had to delete the file by hand to get it rebuilt correctly. The msgs are listed with the correct dates now.

Comment 2

[David :Bienvenu]

trunk builds use received by header for date; I'm going to revert and/or make that optional

Comment 3

[John T]

Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a, this problem still occurs. I sent a test message just now (Jan 4, 7:54 AM) and received it back from a Yahoo listserver showing 1/8/2006 12:26 AM in the date column of the message-list window. But the time (and I suppose the date) shows correctly when I open the message.

Comment 4

[John T]

While it appears that a hidden pref has been added to display the original date (mailnews.display_original_date  default boolean false) it seems to have no effect using build Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060119 SeaMonkey/1.5a. I tried deleting inbox.msf, starting this program and noting that the rebuilt inbox had some of the dates wrong (future dates). After setting the value of the preference to true and exiting the program, I deleted the inbox.msf file again, restarted Seamonkey and found that the dates were still wrong. Neither setting has the intended effect of extracting the dates the old-fashioned way that works on Mozilla 1.7.x.

This is a glaringly noticeable bug in Seamonkey 1.0b and all later versions, one that casual users would readily notice and conclude that Seamonkey has defective programming. The same would be true of Thunderbird if the code is shared.

The date-reading code in Mozilla 1.7.x should be carried over into Seamonkey and Thunderbird because that code works.

Comment 5

[John T]

This is a glaringly noticeable bug in Seamonkey 1.0b and all later versions,
one that casual users would readily notice and conclude that Seamonkey has
defective programming. The same would be true of Thunderbird if the code is
shared.

Comment 6

[David :Bienvenu]

see bug 166254

Comment 7

[WADA:World Anti-bad-Duping Agency]

See Bug 341548 also.

Comment 8

[benc]

So, I'm still unclear on what is the exact problem in the sample message provided:

1- The last "Received" line was parsed wrong, 
2- The "Date" line was parsed wrong.

By parsed wrong, I mean: "the displayed value was Dec3 instaead of Nov30".

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> A test message that I sent just now (Nov. 30) at about 9 AM came back showing
> the date Dec. 3 and time 11:17 PM, though the actual message shows the time and
> date (9:03 AM (no date, implying today)).

Question to clarify:

Other bugs for problem of "mismatch between highlighted mail in thread pane and displayed mail in message pane" exist. This is mainly caused by that thread pane is refreshed but message pane is not refreshed in some circumstances.

To John T(bug opener):
Are you sure that your case is not above problem?

Please see Bug 380808. Even if displayed subject in thread pane and displayed subject in message pane is completely different, it is very difficult to imagine that data of different mails are displayed, when above problem occurs. So, if subject and sender is same, it is usually impossible to imagine that they are different mails.

Comment 10

[John T]

I haven't noticed this problem for some time in SM 1.0x, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12pre) Gecko/20070529 SeaMonkey/1.0.9 at the moment. I don't run 1.1x much but haven't noticed it there for a while either. Linux is my main OS now. Because trunk builds aren't now crashing for me, I'm testing on trunk again, but only tried the mail once. Didn't see the reported problem. The date problem originally reported applies to how the same message is displayed. I don't use the message pane, only the full message display, though I tried it with a trunk build in the past month or two and saw the refresh problem. That's not it. The problem was that the date was parsed wrong in the thread pane. As I recall, it may have involved the particular source of messages involved and not most others.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Do you use same mail folder by release builds and nightly builds?
If yes, see Bug 341548.
I think many of "different or incorrect date" in your environment is phenomenon explained in Bug 341548, except problem of "with dates about 3 days in the future" when mail in Comment #0.
As you say in comment #8, I can't guess why "about 3 days in the future" even though valid Date: or Receieved: header.
Relates to followings?
 - Problem in multi-line header handling had existed, and multi-line Received:
   header is involved in your case.
   So "malformed date" condition might occur on the mail when you downloaded.
 - Bug 142504 – Inconsistent date value for malformed date
   (see attachment of screen shot of the bug)

Can you re-create problem with mail in comment #0?

Comment 12

[WADA:World Anti-bad-Duping Agency]

Attachment: Screen shot of display example of malformed Date: header (Tb 2.0.0.4)

This is screen shot of display of following 3 mails by by Tb 2.0.0.4.
mailnews.display.original_date=false is used (default)
 1. Subject: Test-001
    Date: Pqr, 31 Feb 1965 01:01:01 +0900 (day of the week is corrupted)
 2. Subject: Test-002
    Date: Pqr, 31 Feb 1965 hh:mm:ss +0900 (corruption of time is added)
 3. Subject: Test-003
    Date: Pqr, 31 Xxx 1965 hh:mm:ss +0900 (corruption of month is added)

Result:
(A) test-001 and test-002.
 Different displayed date.
  - 2101/04/08 in thread pane (2101 when 1965 is already reported bug)
  - 1965/03/03 in mail pane
  - When test-002, time is also corrupted. Then 00:00:00 looks to be used.
(B) test-003
 Same displayed datte. 1970/01/01(Epoc time) is displayed.

Different logic / algorythm seems to be used. So I think different displayed date is not so funny phenomenon when malformed/corrupted Date: header or Received: header. And, if your sample mail in comment #0 was considered to had malformed/corrupted date value in message header when mail was downloaded, similar phenomenon might occur.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Additional test result.
 4. Subject: Test-004
    Date: Pqr, 31 Feb 1900 02:02:02 +0900 (day of the week is corrupted)
    => 2036/04/08 08:30 in thread pane
 5. Subject: Test-005
    Date: Pqr, 31 Feb 1869 02:02:02 +0900 (day of the week is corrupted)
    => 2005/04/08 08:30 in thread pane
If date data of message header in your sample mail was considered to be 1869/mm/dd, year of 2005 in thread pane can be explained.

Bug for problem of "2101 when 1965" was Bug 216613. 
> 216613 – when importing some mails' dates are set to year 2101

Comment 14

[John T]

Thank you for your many test cases. As noted, I haven't tested mail on trunk much for quite a while, but got a duplicate of my main profile set up today and found that a trunk Linux build a few days old didn't show the problem in viewing the Nov. 2005 emails that produced the bug. I included a sample header that the date was incorrectly displayed on, and hoped that someone might examine it to see what was causing it. As you note, the dates coming from that discussion group (in contrast to msgs from other groups at the same time) may have been malformed, a Yahoo problem. But the display is working for me now. I'm tempted to say WFM at present. 

However, there perhaps was another bug in the message pane, a missing widget for expanding or collapsing the headers. Is this by design in 2.0a?

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #14)
> I'm tempted to say WFM at present. 
I don't want to bother developers by phenomenon of Comment #12 / Comment #13 when corrupted mail header. And I also think it's better to be closed as WORKSFORME, because your case doesn't involve really malformed/corrupted mail header.

> a missing widget
Trunk still produces many problems every day, and they are resolved every day.
Search bugzilla, please.

Comment 16

[Wayne Mery (:wsmwk)]

WFM per comment 14

Comment 17

[John T]

I concur, haven't seen this problem for a long time.