Closed Bug 1652223 Opened 4 years ago Closed 2 years ago

Date Column shows Wrong Date

Categories

(Thunderbird :: Folder and Message Lists, defect)

Unspecified
Linux
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 402594

People

(Reporter: info, Unassigned)

Details

(Whiteboard: [dupme?])

Attachments

(3 files)

Attached image 20200711104113.png (deleted) —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

When I move some messages from one IMAP folder to another it may occur that the date column shows another date than the date in the header resulting in a weird message listing when you sort by a date column. Often messages from previous years occur to be the most recent and vice versa.

Actual results:

See Screenshot

Expected results:

Header:
Return-Path: <Baufi-NoReply@immobilienscout24.de>
Delivered-To: info@rudolfschmidt.com
Received: from bmx.immobilienscout24.de (bmx.immobilienscout24.de [195.178.100.247])
by rudolfschmidt.com (Postfix) with ESMTP id 9708B11FC2D
for <info@rudolfschmidt.com>; Sat, 25 May 2019 21:22:04 +0200 (CEST)
Received: from is24-mailer (localhost [127.0.0.1]) by bmx.immobilienscout24.de (Postfix) with ESMTP id 4527280ADE
for <info@rudolfschmidt.com>; Sat, 25 May 2019 21:22:04 +0200 (CEST)

Does the message have a "Date: " header line?

Flags: needinfo?(info)
Whiteboard: [closeme 2020-10-20][dupme?]

Yes

Flags: needinfo?(info)

I checked again:

Return-Path: <service@wayfair.de>
Delivered-To: info@rudolfschmidt.com
Received: from rudolfschmidt.com
by rudolfschmidt.com with LMTP
id VSRXKt2QdF5a+yMAd0ZrGA
(envelope-from <service@wayfair.de>)
for <info@rudolfschmidt.com>; Fri, 20 Mar 2020 10:46:05 +0100
Received: from pm05.wayfair.com (pm05.wayfair.com [162.208.32.8])
by rudolfschmidt.com (Postfix) with ESMTPS id 482FF11FC32
for <info@rudolfschmidt.com>; Fri, 20 Mar 2020 10:46:05 +0100 (CET)
Authentication-Results: rudolfschmidt.com;
dkim=pass (1024-bit key) header.d=wayfair.de header.i=service@wayfair.de header.b=OltEi5h3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=pm; d=wayfair.de;
h=From:To:Message-ID:References:Subject:MIME-Version:Content-Type;
i=service@wayfair.de;
bh=sLE+51Nm2llH4BqXjdrJsPZELpuFRD76WR/JS2eci/I=;
b=OltEi5h3MutAIQFnEaMQwWeA6XIViSq8T9WT7xNqFvYzlYNXSVP1N8Ih22+6pHZwqZ6pf91xV5Ym
esNnP05/m0UzpGrkUsEY5NwKoYWHZT/Q2/roVNkqJLG6fjorSczfCIpfWFCnj2IJRvs/NqwsNezL
uznZ/xBWhHSCoE7iZLQ=
Received: by pm05.wayfair.com id hei8dq2l7fsh for <info@rudolfschmidt.com>; Fri, 20 Mar 2020 05:46:04 -0400 (envelope-from <service@wayfair.de>)
From: Service von Wayfair GmbH <service@wayfair.de>
To: info@rudolfschmidt.com
Message-ID: <530540108.1051584697564484.JavaMail.javamailuser@localhost>
References: <email.3744149745@tracking.wayfair.com>
Subject: Deine Stornierung war erfolgreich
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_52_193388045.1584697564475"
X-CSN-MmID: 3744149745
X-CSN-MmOrID: 2806491188
X-Sent-By: JavaSendmail
X-storeid: 368
X-treatmentguid: 16-229
X-origintimestamp: 1584697516072
x-kanamessagetype: FormMessage
x-kxmf-version: KXMF 1.5
x-kxmf-charset: UTF-8
x-kxmf-xmlasatt: TRUE

Why should it has a Date in the header? It should parse the correct Date from "Received"

You see it is received at "Fri, 20 Mar 2020 10:46:05 +0100" and thunderbird shows to be dated at 16.08.20

It's confusing to have a screenshot completely different from your text description. or do I miss something?

What happens, when you repair the destination folder (using folders options dialog → repair)..

The issue appears in many cases, I did find the same mails anymore I used for the screenshot because the issue is open for a long time already.

I used the repair feature today and he created the same issue.

Whiteboard: [closeme 2020-10-20][dupme?] → [dupme?]

why do you close it?
for what do I do this effort if you close it without fixing it?

Do you still see this when using version 78?

(In reply to info from comment #7)

why do you close it?

Nobody closed it

Component: Message Reader UI → Folder and Message Lists
Flags: needinfo?(info)
OS: Unspecified → Linux
Attached image odd_date.png (deleted) —

I think I just hit the same (or similar) issue.
I'm hacking up a tool to generate bulk dummy emails for testing, and I noticed that a whole load of the dates in the "Date" column don't match the "Date:" header.
Loads of my dates are future and historical, and I think it's those that don't work.

Anything before 1970 and anything after about 2100 seem to be affected.
By an amazing coincidence the Unix epoch is in 1970. And by another amazing coincidence, the number of seconds you can store in a 32bit unsigned int gets you from 1970 up to 2106, about where it stops working...
So I think we've got an instance of the year 2038 problem.

I mean, yeah, technically email as we know it wasn't really around until 1972, and we've still got 80-odd years to fix it before it's going to be an issue for new emails... but it doesn't seem right that we can't handle these dates. e.g. I could imagine a service which sends out historically-dated emails (e.g. Pepys Diary )

Attached file bad (deleted) —

Here's an mbox containing just the message from the screenshot.
Copy to "{profiledir}/Mail/Local Folders/bad", and when you start TB it'll pick up the mbox as a new folder, and should show the wrong date.

Flags: needinfo?(info)

(In reply to info from comment #3)

Why should it has a Date in the header? It should parse the correct Date from "Received"

The Date header is set by the sender and represents the time of sending.

The Received column in the TB reflects the time of receipt in the TB.

If TB has access to the Received header, it will use it. Unfortunately, so far this header is only accessible when TB has loaded the entire email.

(In reply to info from comment #6)

The issue appears in many cases, I did find the same mails anymore I used for the screenshot because the issue is open for a long time already.

Yes, the problem has been known for a long time.

I used the repair feature today and he created the same issue.

This reloads the email from the IMAP server, where TB again runs into the same problem: Bug 402594

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Duplicate of bug: 402594
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: