Closed Bug 181034 Opened 22 years ago Closed 17 years ago

Some of the mails imported from OutlookExpress 6 shows incorrect date

Categories

(MailNews Core :: Import, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 216613

People

(Reporter: bv4pc, Assigned: cavin)

References

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826

When I imported mails from OutlookExpress 6 on 2002/11/20, some of them showed
the date as 2101/2/6 whenever they were received. This is annoying when I am
searching/sorting my mails.

Here are the headers of one of them copied from both OutlookExpress and Mozilla
Mail:

[Original Header from Outlook Express 6]
X-RocketRCL: 5679;1;3542382632
X-Apparently-To: bv4pc@yahoo.com.tw via web16403.mail.tpe.yahoo.com; 23 Jan 2002
04:06:40 +0800 (CST)
Received: from daddy.corp.yahoo.com (216.145.56.7)
  by mta112.mail.tpe.yahoo.com with SMTP; 23 Jan 2002 04:06:40 +0800 (CST)
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 8bit
From: Yahoo!©_¼¯¹q¤l«H½c <tw-mail@yahoo-inc.com>
To: bv4pc@yahoo.com.tw
Subject: ¨t²Î¤½§i: POPªA°È§ïÅܤ§­«­n³qª¾
X-Priority: 1 (Highest)
X-MSMail-Priority: High


[When imported to Mozilla Mail, it becomes]

From - Mon Jan 1 00:00:00 1965
X-RocketRCL: 5679;1;3542382632
X-Apparently-To: bv4pc@yahoo.com.tw via web16403.mail.tpe.yahoo.com; 23 Jan 2002
04:06:40 +0800 (CST)
Received: from daddy.corp.yahoo.com (216.145.56.7)
  by mta112.mail.tpe.yahoo.com with SMTP; 23 Jan 2002 04:06:40 +0800 (CST)
Content-Type: text/html; charset=big5
Content-Transfer-Encoding: 8bit
From: Yahoo!©_¼¯¹q¤l«H½c <tw-mail@yahoo-inc.com>
To: bv4pc@yahoo.com.tw
Subject: ¨t²Î¤½§i: POPªA°È§ïÅܤ§­«­n³qª¾
X-Priority: 1 (Highest)
X-MSMail-Priority: High

Reproducible: Always

Steps to Reproduce:
1. Import Mails from Outlook Express
2. 
3.

Actual Results:  
Most of the mails show "received date/time" correctly, while some of them  show
the same "future date/time (2101/2/6 6:28am)" regardless of when they were
received or when they were imported. (Chaneging system date/time gives the same
result.)

Expected Results:  
The date/time should be the same as they were in Outlook Express 6.
I've noticed the same behaviour myself.

It appears that the messages that have a date field in their headers (ie the
majority of messages) appear with their correct dates in mozilla mail. The
messages that have the date 2101/2/6 all have no date field in their header. 

I suspect mozilla just uses 2101/2/6 as the default date for an imported message
and when reading the Outlook Express .dbx file only looks in the message header
for the date. The .dbx format stores the message dates elsewhere in the file - I
propose the import routine be changed to read this field instead of the message
header.
Someone in a German Mozilla newsgroup posted about this problem. So I guess this
bug really exists. ;-) Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Does Mozilla support OE6 mailboxes? I found only some information about 3.x, 4.x
and 5.0. Attachments with a logfile and a minimalized .dbx file could be usefull.

To create a logfile in "c:\importlog.txt"
1) Stop Mozilla
2) Open a command line
3) Enter "set nspr_log_file=c:\importlog.txt"
4) Enter "set nspr_log_modules=IMPORT:5"
5) Start Mozilla from the command line
6) Import the mails
I've looked into this further. 

2101/2/6 does indeed seem to be the default value for a message's date in 
mozilla mail, and this is used if the message has no other date information. 

First Mozilla looks for a "date" field in the message header, but not all 
messages have one. 
Then it looks at a "From" field in the mailbox file for the "recieved at" date.
If that fails, it uses the default, 2101/2/6.

This is important, because looking at the source, the "recieved at" date is not 
transferred from the Outlook Express .dbx file to the mozilla mailbox "from" 
field. Therefore, when the message header doesn't have a "Date" field, Moz.Mail 
defaults..
It is debatable whether this is a bug or not, since according to RFC 2822 every
mail MUST have a "Date:" header field, so mails without that are broken anyway.
There is no way to determine when such a mail was actually sent.
I'm attaching a Mozilla mail file with a single mail (contents XXXXed). This
mail was imported from Outlook Express 6, _has_ a Date header (a valid one as
far as I can see) which is shown correctly in the Mail window. Even so, the
date in the overview window is "2101/02/06", so I think the bug is not in the
mail, but in Mozilla
Really? Looking at that mail header I don't see a date field. There's dates on a 
few of the other fields, but that's not where Mozilla gets the dates from...
Perhaps I destroyed readability of the header somewhat with my "XXX"ing, but
"Date: Sun, 16 May 2004 22:40:31 +0200" clearly looks to me like a Date header.
Besides, as I wrote in my earlier comment, the date is even shown correctly in
the head of the mail window (see attached file), just in the mail overview it
is "2101/02/06".
Product: MailNews → Core
*** Bug 276938 has been marked as a duplicate of this bug. ***
*** Bug 306306 has been marked as a duplicate of this bug. ***
*** Bug 321885 has been marked as a duplicate of this bug. ***
If the "Date:" header missed, why not use "Delivery-date:" field?
http://luch-mgsu.msk.ru/misc/thunderbird-import-bug.jpg
(In reply to comment #0)
> When I imported mails from OutlookExpress 6 (snip),
>  some of them showed the date as 2101/2/6
>
> [When imported to Mozilla Mail, it becomes]
> From - Mon Jan 1 00:00:00 1965
>(and no Date: header)

Read Bug 216613 Comment #11, please.

I think Bug 181034 and Bug 216613 are better to be consolidated to single bug, because apparently duplicate bugs for same symptom/problem/defect. 
Yeah, duping to bug 216613...
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: