User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Build Identifier: version 1.0.6 (20050716) Mail sent using Outlook 2002 and placed in the Sent folder (and which, therefore, has no headers) is given an date when imported. For me, the date in TB is always 6 hours too early. Since I am in GMT-6, it seems that TB is interpreting the dates in GMT instead of my local timezone. Reproducible: Always

(In reply to comment #0) > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) > Build Identifier: version 1.0.6 (20050716) > Mail sent using Outlook 2002 and placed in the Sent folder (and which, > therefore, has no headers) is given an date when imported. For me, the date in > TB is always 6 hours too early. Since I am in GMT-6, it seems that TB is > interpreting the dates in GMT instead of my local timezone. > Reproducible: Always Sorry, that should say "an incorrect date when imported".

Interesting. When I look at mail sent from Outlook via Exchange to my mail client, I see: Date: Thu, 28 Dec 2006 16:42:10 -0800 Is that being added by Exchange?

If I'm reading this correctly, the claim is that the copy that Outlook puts in the Sent folder doesn't have a Date: header, but the copy sent to the mail server does (or the mail server adds a Date: header). Well, nothing Outlook does surprises me much anymore :-)

Confirming based on dupe.

It should be noted that this includes not only sent items in the Sent folder, but wherever they may be archived. Any estimate of when this will be looked at? It's really the only reason preventing yours truly and others in the office from using Thunderbird.

(In reply to comment #2) > Interesting. When I look at mail sent from Outlook via Exchange to my mail > client, is that like bug 319268? (old v1)

(In reply to comment #6) I agree 100%. Sent items (without headers), whether imported from the "Sent Items" folder or elsewhere, have the wrong time information leading to great confusion when mixed with received and correctly dated messages. A correct date is a must have feature.

Maybe we need to distinguish between Outlook being imported from an Exchange server and Outlook mail being imported from a PST file. I imported an Outlook 2003 PST file (Unicode) and on the sent items, the import process inserted this date in the header (I removed the from/to headers for privacy): From - Fri, 5 Mar 2010 09:29:12 Date: Fri, 5 Mar 2010 09:29:40 +0100 Content-type: text/html; charset=windows-1252 MIME-Version: 1.0 Content-transfer-encoding: 8bit TB displays the time as 09:29. Sadly, that's not correct. The message was sent at 10:29 local time, so it fact at 09:29 GMT. So I've been considering to write a script to go through all the imported folders and replace +0100 with +0000.

Here's the Perl script in case anyone cares ;-) =============== if ($#ARGV < 0) { print STDERR "usage: fix_date <input>"; exit 1; } my ($input) = $ARGV[0]; my($new_msg); my($l1,$l2,$l3); die "$input: $!\n" unless open (W,$input); my ($output) = $input . "-date-fixed"; open (O,">" . $output); $new_msg = 0; # Logic relies on the fact that for sent messages we have these headers in this order # From - # To: # Date: foreach (<W>) { if (/^From -/) { $new_msg = 1; $l1 = $_; } if ($new_msg == 2 && ! /^Date:/) { $new_msg = 0; } if (/^To:/ && $new_msg == 1) { $new_msg = 2; $l2 = $_; } if (/^Date:/ && $new_msg == 2) { $new_msg = 0; $l3 = $_; # print "\nFixing\n"; # print "$l1"; # print "$l2"; # print "$l3"; print "Fixing message $l2"; s/ \+0100/ \+0000/; } print O $_; } close (W); close (O);

I fixed this bug, here is the patch. But I need help to create it correctly: ======== $ diff -u MapiMessage.cpp-org MapiMessage.cpp --- MapiMessage.cpp-org 2010-04-23 15:57:55 +0200 +++ MapiMessage.cpp 2010-04-23 16:34:36 +0200 @@ -192,7 +192,10 @@ if (!str.IsEmpty()) str += "\x0D\x0A"; str += "Date: "; - FormatDateTime( st, str); + // FormatDateTime does not append the correct time zone. + // Let's do it here, all times are UTC, so it's just +0000 + FormatDateTime( st, str, FALSE); + str += " +0000"; } }

Very simple and obvious change. All times in question are UTC, so it's nonsense to append the local time zone. If you do, your time will shift by as much as you are away from Greenwich. The Perl script submitted before undoes the damage when e-mail has already been wrongly imported. It needs to be modified to suit the users time zone. I had to replace +0100 with +0000, but for folks in other parts of the world, that needs to be adapted. Also, the script very simple heuristics to identify sent mail. In short, use the Perl script at your own risk, if you know what you are doing!!

Jorg, thx for the patch. Are you saying that ::FileTimeToSystemTime always returns a UTC (GMT) time?

Yes, as long as you trust Bill: http://msdn.microsoft.com/en-us/library/ms724280%28VS.85%29.aspx

Comment on attachment 441040 [details] [diff] [review] Don't append local time zone to UTC times. If you do, they shift, so don't! this looks reasonable - I'll probably tweak the comment to say that FileTimeToSystemTime gives us UTC time...thx for the patch.

Don't append local time zone to UTC times. If you do, they shift.

Oops, didn't check the "patch" check-box.

Jorg: please set the review/superreview flags also so the patch gets reviewed. http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree#Getting_the_patch_reviewed

Sadly the same source file is also affected by Bug 250878, so this change is also reflected in the patch for the other bug. People applying the patch, please coordinate. If you apply the other patch first, this one can be discarded.

Comment on attachment 441247 [details] [diff] [review] Due to popular demand, now with improved comment ;-) this looks fine. I'm having trouble getting outlook import to work at the moment (I suspect it's an issue with 64 bit windows 7 and Outlook 10, but I haven't been able to debug it)

Comment on attachment 441247 [details] [diff] [review] Due to popular demand, now with improved comment ;-) Sorry for the delay in getting to this. I've been able to test it and it works fine. Thanks for the patch!

Checked in: http://hg.mozilla.org/comm-central/rev/218413802a0d

Comment on attachment 441247 [details] [diff] [review] Due to popular demand, now with improved comment ;-) I think we'll also consider taking this for 3.1.1.

Checked in to 1.9.2: http://hg.mozilla.org/releases/comm-1.9.2/rev/aeb412d8df1f