540392 - Wrong time/date of filtered messages

Status: RESOLVED DUPLICATE of bug 32216

(Thunderbird :: General, defect)

Description

[arnost.zlicin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 

I have a filter that chooses messages from input messages and moves them to the specific folder. Actually it moves messages whose subject contains word "SVN" and moves them to the SVN folder. In this folder, messages are always reported as received on 1.1.1970. I checked the source messages (Ctrl-U) and date/time inside them is ok.

If I do it manually and move a message from input to SVN folder by drag'n'drop it works fine (date/time is correct). Moreover, other filters with the very similar pattern (subject contains -> move to) work fine as well. 

Reproducible: Always

Steps to Reproduce:
1. Create a filter: "Subject contains 'A'" and "Subject contains 'B'" than move message to folder 'C'
2. Receive a message that the filter can be applied on

Actual Results:  
Date/time of the moved message in folder 'C' is always showed as 1.1.1970 1:00 

Expected Results:  
Date/time should be preserved and shown correctly

The header from the message with wrongly indicated date/time (1.1.1970 1:00):

Return-Path: <XXXX>
X-Original-To: <XXXX>
Delivered-To: <XXXX>
Received: from <XXXX>
	by <XXXX> with ESMTP id 5D8572527C0
	for <XXXX>; Fri, 15 Jan 2010 09:49:11 +0100 (CET)
X-Sagator-RegExp: LOCAL_IP
X-Spam-Checker-Version: SpamAssassin 3.1.7-deb3 (2006-10-05) on 
	<XXXX>
X-Spam-Level:
X-Spam-Status: No, score=1.0 required=7.0 tests=AWL,BAYES_00,INVALID_DATE,
	MIME_BASE64_NO_NAME,NO_REAL_NAME autolearn=no version=3.1.7-deb3
X-Sagator-Scanner: 1.0.0-1 at mail;
	log(status(quarantine(drop(ParseMail(attach_name(), attach_name(),
	file_type()))))) status(report(drop(quarantine())))
	status(report(drop(quarantine(SpamAssassinD()))))
X-Sagator-ID: 20100115-094911-0001-02907-vvyMfs@mail
Received: from <XXXX>
	by <XXXX> with ESMTP id D2685141BC27
	for <[e-mail]>; Fri, 15 Jan 2010 09:48:57 +0100 (CET)
Delivered-To: <XXXX>
Received: by <XXXX> (Postfix, from userid 33)
	id 078B8141BC2A; Fri, 15 Jan 2010 09:48:56 +0100 (CET)
Date: Pá, 15 led 2010 09:48:55 +0100
To: <XXXX>
From: <XXXX>
Message-Id: <XXXX>
X-Topics: trunk
Subject: [Svn-commit] [trunk] r20860 - lib/vital/trunk/mod
X-BeenThere: <XXXX>
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: svn commit announces <XXXX>
List-Unsubscribe: <XXXX>,
	<XXXX>
List-Archive: <XXXX>
List-Post: <XXXX>
List-Help: <XXXX>
List-Subscribe: <XXXX>,<XXXX>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: <XXXX>
Errors-To: <XXXX>

Comment 1

[arnost.zlicin]

If anyone can remove my email address from the description, please do so. ;-( I made a mistake while filtering to <XXXX>.

Comment 2

[WADA:World Anti-bad-Duping Agency]

> Date: Pá, 15 led 2010 09:48:55 +0100
> I checked the source messages (Ctrl-U) and date/time inside them is ok.

Why can the Date: header be correct?

> X-Mailman-Version: 2.1.11

Same phenomenon as bug 32216.
Malformed Date: header probably caused by over localization of Mailman.

> If I do it manually and move a message from input to SVN folder by drag'n'drop
it works fine (date/time is correct).

Which value?
  Date column of thread pane,
  Received column of thread pane,
  Date headr field at header box of message pane
Same as first "From - ..." line of View/Message Source?

> In this folder, messages are always reported as received on 1.1.1970.

POP3(or Local aol Folders)? IMAP?
If IMAP, and if Received column, see bug 402594.

Comment 3

[arnost.zlicin]

Ad Date) Sorry, I completely missed the fact that it should not have been localised. Therefore I though it was ok.

It seems it is really duplicate of bug 32216. :-(

Unfotunately, it works fine with TB 2 so I was surprised that it does not work in TB 3. Maybe you did some workaround in TB 2 that you don't want to support any longer.

I'm sorry once again for duplicated bug.