Closed Bug 32216 Opened 20 years ago Closed Last year

Mail date 1.1.1970(or 12.31.1969) when Date: header is localized or malformed

Categories

(MailNews Core :: MIME, defect)

x86
All
defect
Not set

Tracking

(thunderbird_esr6064+ fixed, thunderbird64 fixed, thunderbird65 fixed)

RESOLVED FIXED
Thunderbird 65.0
Tracking Status
thunderbird_esr60 64+ fixed
thunderbird64 --- fixed
thunderbird65 --- fixed

People

(Reporter: christophe, Assigned: jorgk)

References

(Depends on 1 open bug)

Details

Attachments

(6 files, 2 obsolete files)

From Bugzilla Helper:

User-Agent: Mozilla/5.0 (Windows; N; NT4.0; en-US) Mozilla/M14 de-AT

BuildID:    2000022820



Mails with localized, e.g. German, Date: tag in the header appear with date

1.1.1970. Only english date/time abbreviations are properly recognized.



Reproducible: Always

Steps to Reproduce:

1.create mail with non-english date: tag in header	

2.send and receive mail
3.
sort mails by date




Actual Results:  mail programs states that mail was sent 1.1.1970



Expected Results:  mail date should be, e.g., 03-17-2000.



english date tag in header:

Date: Fri, 17 Mar 2000 12:29:40 +0100



german date tag in header:

Date: Di, 14 Mrz 2000 16:56:44 +0100



Perhaps, it's safer to sort by the time stamp of the smtp server.
Target Milestone: M14
Someone, please check this out and confirm this bug. I can't do it
until Monday.
>1.create mail with non-english date: tag in header 
Could you tell me how to do that? I am not familiar with localization.

Tao, are we using localized dates in 4.x? I am using 4.7 japanese but not see 
localized date string in a mail header.

Date: Mon, 31 Jan 2000 19:11:43 -0800
From: Naoki Hotta <nhotta@netscape.com>
X-Mailer: Mozilla 4.7 [ja] (Win98; I)

cc to rhp, putterman, ducarroz.
In RFC, there is a section for "DATE AND TIME SPECIFICATION".
ftp://ftp.isi.edu/in-notes/rfc822.txt

It deos not inlcude localized strings. So the date in header should not be 
localized.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
The actual mail headers as defined by the standard which nhotta cites uses
English as a "canonical" format -- nothing we can do about it.

In the thread pane, we should display a localized date format.  Isn't that
working?
Yes, the thread pane can display localized date format.
A non-english Date: tag can't be created with Netscape, but some other software 
unaware of RFC 822 does!
Netscape/Mozilla does not properly read in the -erroneous localized- date/time 
and therefore writes 1.1.1970.
The latter dat/time is correctly localized. - Christophe Veber
Do you have a suggestion on how to deal with non-standard date headers?
How does a receiving mail-agent know which localized version to parse when
receiving a mail message?  It would be impractical to build in special handling
for every possible illegal header.  

Headers must be canonical to ensure interoperability.  It is unfortunate that
the RFC uses US-English date strings for the canonical date format...

Do you know which mail-agents generate these illegal email headers?  And how
wide-spread are they used?  Do other popular mail-agent (e.g., Outlook,
Eudora) handled these?
Outlook (Express), KMail and XFMail properly sorted mails with non-standard 
Date: tags. I guess they sort mail by the date of the smtp server, that is, the 
date/time coming with the first Received: tag. I think this approach is safer 
than anticipating thousands of mail clients.
hmmm, interesting.  So the Received headers include dates formatted according
to RFC 822, and it's only the Date header which uses the non-compliant date
format?

Can you attach a copy of these mail messages, so we can use it for testing?

We should look into this. Should we use the dates from the 1st Received header
instead of the date from the Date header?  Reopening this bug for another
evaluation.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I don't know how to forward within the Bugzilla system, so I forwarded sample 
mails with a localized Date: tag to the persons in the cc: list. If you didn't 
get it properly, please tell me. - Christophe Veber
> Outlook (Express), KMail and XFMail properly sorted mails with non-standard 
> Date: tags.
Are they also display the dates properly?
Hi Christophe,

Who did you forward the mail to?  I have not received anything.

To include an example in the bugzilla report, please save one of these emails
in its raw form (including the headers) to a plain text file, then you click
on the "Create a new attachment" (below "Summary", "Status Whiteboard" and
"Keywords"), and then attach the plain text file to the bug.
Outlook, etc., also display the date properly.
One more question, does outlook seem to be using the server time stamp or 
interpreting the localized date?
Outlook seems to use the server time stamp.
When we say the "server time stamp", do we mean the date-time of the earliest
Received header?

Using the Received header date-time insteaded of the Date orig-date seems to be
wrong, although practically they are probably pretty close (unless the clocks
on the 2 systems our out of sync as in the attached example).

If we wanted to do the "right" thing, could we look at the Received header only
if the Date header is malformed?

I see 3 choices: (1) Do nothing and be "correct" but be user-unfriendly and
appear to fail as compared to competitive products, (2) Use the earliest
Received header, but be technically incorrect, or (3) Use the earliest
Received header only if the Date header is malformed.

Ignoring implementation issues, I favor (3).

I'd guess that normally we do not parse the Received headers and that we
would not want to unless necessary.  If the Date header is malformed, is it
easy to grab the Received headers at that point and then to parse them?
I don't know the sources. but from the above problem it seems to me that an 
error or undefined value can't be distinguished in Mozilla from a correct date.
I don't know the source either, but it is must parse the string.  "Di" and
"Mrz" are not going to recognized as valid tokens and I assume that is why
the date is being reported as 1.1.1970.

So I guess we can catch the malformed date headers pretty easily, but then
we need to grab the earliest Received header and parse its date string.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassign to ducarroz (or please reassing to the right person).
Please implement the third option mentioned by bobj's comment (2000-03-21 
01:35).
Assignee: nhotta → ducarroz
Reassign to rhp
This time is really reassigned!
Assignee: ducarroz → rhp
Status: NEW → ASSIGNED
Target Milestone: M14 → M20
I think this is working for me...I tried the attached message and it looks 
correct. Possibly someone can verify.

- rhp
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
I'm going to pass this on to marina.
The test message simply did not show any header with 9/11/2000 Win32 build.
I thought that there is dependency on there being a first line
like this:

From - Wed May 05 14:37:44 1999

The test message does tno contain this and the header does not show
in thread pane at all -- including the dates. 
if you supply the correct date in the above format, it does show.
I wonder how people were testing this to re-produce the problem.
Good luck.
QA Contact: momoi → marina
i am verifying it as wfm ( reporter can add comments if he still has a problem)
Status: RESOLVED → VERIFIED
Problem not resolved:
I use
Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011128 
Netscape6/6.2.1.
When I receive mail with a localized Date: tag, Netscape Mail shows it as 01-01-
1970.
Christophe Veber
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
I am not sure i'll be able to test this bug:
- when changing regional default locale settings the Western Europe and USA have
the same format in Date.Unfortunately i am not able to chose a long format for
date display, mozilla uses a short one by default, so i can not get a mail to
display day/month/year in d/mmmm/yyyy. We have to have an option in Prefs to be
able to chose between short and long format. ( actually it is possible to chose
a different default locale for Japanese and using the short format mozilla sorts
mails with the localized tags just fine, Xianglan tested this).Well, my guess is
that the SMTP server stamps the mail, we dont have a localized server here, the
testing message that Christophe attached shows up as a blank folder probably
because of its localized tags. It looks like i'll need the reporter help to
verify this bug when it'll get fixed. 
After editing the mail header (changing date into a bogus name) i was able to
see this problem in my local folder. The edited mail was stamped as
12-31-1969....So we can reproduce this problem (differently) in house.
The behaviour depends on the Date: stamp of the sending mail app, not on the
date given in the various Received: entries in the header which are created by
smtp servers.
I don't think this problem depends in short/long date display.
Cristophe, you're right, in my last comments i've said that after changing the
date stamped by the sending server to a bogus one i was able to reproduce this
bug. I mentionned long format as opposed to short as a way to reproduce it.. I
don't need  mozilla displaying a long format now when i know another way to see
this bug. 
How will you solve this?
Afaik, the Date: stamp must not be localized (see RFC 822 mentioned above),
parsing the Date: using the client's localization would be convenient, but not
necessarily compliant.
The problem we talk about here is caused not be Outlook or Communicator, but by
ill-tested client software, so perhaps it is safer to get the date by which
mails are sorted from the Received: tag(s) of the smtp server(s): a) The
probability is higher that their time is correct, b) th probability is higher
that the date/time is given by an english, unlocalized server software.
<How will you solve this?
Cristophe, please read comments #17 from bobj, especially (3) that he favors for
malformed headers.
OK, (when) will this issue be solved?
reassigning to ducarroz
Status: REOPENED → ASSIGNED
Really reassign to me...
Assignee: rhp → ducarroz
Status: ASSIGNED → NEW
i am getting more and more mails stamped with incorrect day, now they are
arriving as year 2029 or 1969. The way the server/client talk now introduces a
lot of inconviniences for the user when the date tag is localized or malformed.
It gets filed at the bottom or the top of your Inbox according to the way you
sort and it is easy to disregard and miss such mail. I think we have attend to
this problem and  fix it as soon as our resources allow us... Changing the summary
Summary: Mail date 1.1.1970 when Date: tag localized → Mail date 1.1.1970 when Date: tag localized or malformed
Status: NEW → ASSIGNED
Keywords: nsbeta1
Keywords: nsbeta1nsbeta1+
Priority: P3 → P2
Target Milestone: --- → mozilla1.0
I don't think we're going to be doing this any time soon.  Renominating for
reconsideration by triage team.
Keywords: nsbeta1+nsbeta1
Target Milestone: mozilla1.0 → ---
Discussed in 2/25 bug meeting with Mktng, PjM, Engineering.  Decision to minus
and future.
Keywords: nsbeta1nsbeta1-
related to bug 131983?
Don't think so. Date: tag in  bug 131983 looks OK and _not_ localized.
Christophe Veber
Can someone take a look at bug 132779 and dupe it to this if it looks similar
enough?
I am tempted to mark both bugs #131983 and #132779 as dups of this one. This bug
is a more general case and talk not only about localized headers but also about
malformed headers that eventually would be stamped as 1/1/1970 or 12/31/69. Bob,
could you please look into it?
i take my previous comments back, the other two bugs are not dups or this one,
even though the results look the same and might confuse about the cause. Let's
leave this bug as dealing with localized headers only and i post my comments
about other two( that might be dups between them) on #131983
Maybe its offtopic there, but I see same bug without localised date in mail. Now
I have 5 mails in inbox, dated 01.01.1970.
No one (as I can see) havent localized date. 4 from it have normal date when
viewing message - in preview pane, or in single window.

1 of this message have incorrect date (with y2k bug - from old version of elm -
and contayn 102 year :) )

for example this is header from non-localized-date message, correctlu showed in
message pane, and incorrectly showed in message list like 01.01.1970 02:00:
(addresses is bastardized by adding random letters - against spam-bots)
---------------------------------------------------------------------------
From - Tue Mar 05 16:20:21 2002
Received: from server1.btv.lv (mail.btv.lv [217.198.224.80])
	by sun3.lateko.lv (8.9.3/8.9.3) with ESMTP id QAA12768
	for <iavz@latekoz.lv>; Tue, 5 Mar 2002 16:19:39 +0200 (EET)
Received: from r3u6i4 (unknown [10.20.239.18])
	by server1.btv.lv (Postfix) with SMTP
	id 28328FA44D; Tue,  5 Mar 2002 16:19:39 +0200 (EET)
Message-ID: <006e01c1c450$9bf2e860$12ef140a@btv.lv>
From: "Aleksandrs Volperts" <quizz_1@mboxi.riga.lv>
To: "Igor Velkov" <iavz@latekoz.lv>, "tink" <tinkz@lpstudioz.net>
References: <3C84B1B5.C30204D@latekoz.lv>
<144436927488.20020305082010@lpstudioz.net> <3C84D04C.29A09F85@latekoz.lv>
Subject: =?koi8-r?B?UmU6IFtGd2Q6IERFTEZJIC0g5M/Fwcza2iDJzNXW3iDOxc/F1NXK3g==?=
	=?koi8-r?B?IN/BzdfZysXJ0M/NzMzR18HFz9/VPV0=?=
Date: Tue, 5 Mar 2002 16:17:56 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 1159
Status:   
X-Mozilla-Status: 8003
X-Mozilla-Status2: 00000000
X-UIDL: 3bce7c4a000010af



Мои старые болванки датируются 98 годом. Никаких проблем с ними не было.
I tried the message in comment #44 using 4/26 commerical branch.
The subject was blank but date was shown as "3/5/2002 6:17 AM" and sender shown
as "Aleksandrs Volperts". I got a same result using 4.x.
It might be caused by bug 131983, please try using the latest build.
*** Bug 142504 has been marked as a duplicate of this bug. ***
It seems that there is another strange format of date-since-1900 in use.  Have
attached a sample.
Thks.
Is the behaviour shown in attachment (id=87035) really identical
to my submission (id=6738)?
Peter Woo's Date: tag looks RFC-compliant. Perhaps this is rather a Y2K
problem?
Blocks: 157673
could someone summarized a list of mailer which will produce these localized
date in the RFC822 headers?
Bug 73565 may be a duplicate.
*** Bug 180254 has been marked as a duplicate of this bug. ***
Frank Tang: Do you want to assess the relevance of the flaw or do you want a
mailer that creates malformed Date: tags?
simon will take a look at this bug and summarize it to see where the problem
arises specifically. 
Keywords: nsbeta1-nsbeta1
Win32 app that sends german localized Date: tag.
The program can be used to see if Netscape mailer behaves correctly.
Simon:
Perhaps the demo mailer helps?
Was comment #54 about which mail programs send mailformed Date: tags?
Some bulk mailers do, like StreamServe MailOut 3.0. Otherwise, see comments #8, #31.
Perhaps there is no way to handle all date formats in the world (including
erroneous formats...).  Actually, is it applicable that for unrecognized dates
(such as those 1900's), Mozilla simply assigns the PC datetime stamp to it?
See comment #8 ff.: You could use the Received: tag of the SMTP server instead
or as a fall-back.
It seems to be Mozillas intent to use the date when the mail was sent as the
sorting criterium, not the reception time. Therefore, using the Received: tag is
more consistent.
Will this bug be fixed soon? This was opened 2000-03-17 !
reassigning to smontagu and marking nsbeta1+ per mcarlson
Assignee: ducarroz → smontagu
Status: ASSIGNED → NEW
Keywords: nsbeta1nsbeta1+
Info: The bug is not fixed in the following versions of Netscape & Mozilla:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0
OS: Windows NT → All
Target Milestone: --- → mozilla1.4beta
i18n triage team: nsbeta1-
Keywords: nsbeta1+nsbeta1-
date time was displayed as 06/02/2101 06:28 

it was actually 01 dec 2003 13:20:06
Product: MailNews → Core
Set Bug 73565 as "Depends on:" of this bug, which is bug for "No Date: header" case.
Depends on: 73565
*** Bug 288681 has been marked as a duplicate of this bug. ***
*** Bug 293252 has been marked as a duplicate of this bug. ***
*** Bug 293515 has been marked as a duplicate of this bug. ***
No longer blocks: 300832
*** Bug 300832 has been marked as a duplicate of this bug. ***
works with Firebird Version 1.0.6 (20050716).

Nice to see that - but: what this fix intentional?
Status: NEW → RESOLVED
Closed: 20 years ago15 years ago
Resolution: --- → FIXED
(In reply to comment #68)
> works with Firebird Version 1.0.6 (20050716).
> 
> Nice to see that - but: what this fix intentional?

Firefox? Where is firefox parsing a "date" "header"?
Sorry - I mixed it up: I meant Thunderbird, of course.
I don't see any evidence of a patch that was checked in or reference to another
specific bug that fixed this.

-> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → WORKSFORME
who will verify/close this?
I have several e-mails with the date in the formats:

Date: WED,22JUN2005 21:14:15 -0500
or
Date: ¿ù, 04 7 2005 03:29:06 +0100

These show up as 12/31/1969 4:00 p.m. in Thunderbird 1.0.6 (20050716)
(In reply to comment #68, comment #70, comment #71, comment #72)
To Christophe Veber(who changed to FIXED at 2005-07-30 02:29 PDT)
 and Jason Bassford (who changed to WORKSFORME 2005-07-30 06:48 PDT) :
Could you attach evidence of "FIXED" or "WORKSFORME", please.
 (1) Malformed Date: header which was displayed "correctrly" by your Thunderbird.
 (2) Displayed "correct" date by your Thunderbird when malformed Date: header.
     - What was displayed?
     - Where it was displayed? 
Summary: Mail date 1.1.1970 when Date: tag localized or malformed → Mail date 1.1.1970(or 12.1.1969) when Date: tag localized or malformed
Summary: Mail date 1.1.1970(or 12.1.1969) when Date: tag localized or malformed → Mail date 1.1.1970(or 12.31.1969) when Date: tag localized or malformed
Christophe Veber, do you set mailnews.display.original_date to true?
for comment #74:
(1) The attached header displayed properly with my Thunderbird (version 1.0.6
(20050716), german WinXP).
(2) In Thunderbird, my Inbox mails are sorted by "Date", with the mail with the
malformed Date: appearing correctly on top (displaying "17:25" for today)
for comment #75:
No, the setting is
...
pref("mailnews.display.original_date", false);   // display date string from
mail headers without interpreting
...
(In reply to comment #76 & comment #77)
Your case, original case of this bug and "localized but well formed date header"
case, looks to be resolved in your environment.
But according to comment #73, problem when "localized header" still exists
apparently even when "malformed" is "localized weekday" only.
Problem when "corrupted date header" is not resolved yet too.
Christophe Veber, please keep this bug OPEN, since this bug already involves
"malformed/corrupted date header" case, and since many bugs are already closed
as DUP of this bug.
cf comment #78
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This started happening to me today in Thunderbird 1.5 beta 1. It worked in "Aug"
and "Sep" (regardless of the weekday), but now is "Okt"/"Oct" and some mails get
tagged as 01.01.1970.
The "Received" headers have the correct English format.
Changing conmonent from "MaiNews: Internationalization" to "MailNews: MIME",
because "malformed Date: header" handling problem.
Component: MailNews: Internationalization → MailNews: MIME
Reassigning to default bug owner due to component change.
Assignee: smontagu → nobody
Status: REOPENED → NEW
QA Contact: marina
At last, David has started to care on "No Date: header" case in Bug 166254.
Depends on: 166254
*** Bug 299114 has been marked as a duplicate of this bug. ***
*** Bug 295208 has been marked as a duplicate of this bug. ***
*** Bug 364584 has been marked as a duplicate of this bug. ***
Priority: P2 → --
Target Milestone: mozilla1.4beta → ---
mailnews.use_received_date=false(default)/true is added to latest-trunk
nightly, and user can choose mail-date(date in "Date column") from Received:
instead of from Date: header now. This enhancement can be a relief of this bug's
case for some(I think many) users. See Bug 341548 for detail.
Duplicate of this bug: 385708
QA Contact: mime
Product: Core → MailNews Core
mailnews.use_received_date was unfortunately landed on Tb2, but it removed from Tb3. Tb3 introduced "Received" column unstead. See bug 166254.
Duplicate of this bug: 536746
Summary: Mail date 1.1.1970(or 12.31.1969) when Date: tag localized or malformed → Mail date 1.1.1970(or 12.31.1969) when Date: header is localized or malformed
Duplicate of this bug: 540392
This bug was started 2000-03-17. Today is 2013-01-22, and the bug is still alive and well. Could we please get a bit of action on this bug? According to comment #8, other programs handle incorrectly formatted dates, also posted back in year 2000.

Voting +1 for me. I happen to be running on:

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15
Build identifier: 20130105222033

The official Mozilla build installed via UbuntuZilla.
Oh, per comment #87 on this thread, that preference is not in my build of SeaMonkey. Nothing comparable appears when searching for preferences via: mailnews.*date*
Blocks: 612990
Duplicate of this bug: 612990
I'm not sure if this is the right issue, correct me if I'm wrong:

I received an email with the following header:
Date: =?Windows-1252?B?RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==?=

but the date is displayed as 01.01.1970 01:00 in Thunderbird 38.1.0.

Is this header malformed or is thunderbird just not able to read it unlike other applications (e.g. K-9 Mail on Android is displaying the correct date)

Should I open a new issue?
(In reply to Peter from comment #95)
> I'm not sure if this is the right issue, correct me if I'm wrong:
> 
> I received an email with the following header:
> Date: =?Windows-1252?B?RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==?=
> 
> but the date is displayed as 01.01.1970 01:00 in Thunderbird 38.1.0.
> 
> Is this header malformed or is thunderbird just not able to read it unlike
> other applications (e.g. K-9 Mail on Android is displaying the correct date)

Yes, that is a seriously malformed header. Date is a structured header, and RFC 2047 encoding an entire structured header is illegal. Please contact the author(s) of the application that originated said message and inform them that their application is seriously broken in this regard.
(In reply to Peter from comment #95)
> I received an email with the following header:
> Date: =?Windows-1252?B?RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==?=

?B? means base64-encoded.
https://tools.ietf.org/html/rfc2047#section-4
https://tools.ietf.org/html/rfc2231

$ echo 'RnJpLCAxNyBKdWwgMjAxNSAxNTo1ODoyNyArMDIwMA==' | base64 -d
Fri, 17 Jul 2015 15:58:27 +0200

I'm not sure RFC 5322 allows this format.
https://tools.ietf.org/html/rfc5322
Turns out Peter's issue has already been discussed in bug 276199
(RFC-2047-encoded Date header not parsed or displayed correctly)
=> RESOLVED INVALID
I've got a date header as

date: 2017-11-15T09:52:25.025

that shows up as 01/01/1970 00:00
(In reply to Craig Emery from comment #99)

> I've got a date header as
> 
> date: 2017-11-15T09:52:25.025
> 
> that shows up as 01/01/1970 00:00

AFAIU, the date shown is in ISO 8601 format.

https://en.wikipedia.org/wiki/ISO_8601

However, the Date format for emails is specified by RFC 5322

https://tools.ietf.org/html/rfc5322#section-3.3

The two are not compatible.

(FWIW, I think it would be slightly better to display the Received date, instead of the beginning of the epoch, when the header cannot be parsed or doesn't exist.)
Comment on attachment 9018834 [details] [diff] [review]
If the 'Date' header is invalid, use date from 'Received' header instead.

If the 'Date' header is invalid, use date from 'Received' header or current time (if
their is no 'Received' date) instead.

This uses also to the date from 'Received' header, if there is no 'Date' header and
no envelope.
Attachment #9018834 - Flags: review?(jorgk)
(In reply to Alfred Peters from comment #102)

> This uses also to the date from 'Received' header, if there is no 'Date'
> header and no envelope.

See also:
Bug 73565: Messages that lack a Date: header are displayed as "sent in 1969/12/31"(or 1970/01/01, Epoc time)
Bug 266434: if msg doesn't have a Date: header, we use the time we received the message
Bug 512930: If mail of no Date: header is copied to IMAP folder, today is set as date of the mail (Tb's date
            display for no Date: header, malformed Date: header is inconsistent)
Attachment #6738 - Attachment is patch: false
Attached patch bug32216.patch (JK, v1) (obsolete) — Splinter Review
This is ugly all over. I added a bit more "Meister Proper":
- Variable deliveryDate is really not needed.
- No need to convert seconds back to PRTime if you
  grab the received time when it's available, that simplifies
  the branch were you get 'now'.
- 'dateValue' wasn't a great variable name.
- There was no need to store status values.
- Moved the comments where they should go.

Should we check 'rcvTimeSecs' before calling?
m_newMsgHdr->SetUint32Property("dateReceived", rcvTimeSecs);
Assignee: nobody → jorgk
Attachment #9018931 - Flags: feedback?(infofrommozilla)
Attachment #9018834 - Flags: review?(jorgk)
Comment on attachment 9018931 [details] [diff] [review]
bug32216.patch (JK, v1)

Review of attachment 9018931 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Jorg K (GMT+2) from comment #104)
> Created attachment 9018931 [details] [diff] [review]
> bug32216.patch (JK, v1)
> 
> This is ugly all over. I added a bit more "Meister Proper":

Looks good for me.

> Should we check 'rcvTimeSecs' before calling?

Unixtime should be an integer with values from 0 (1 January 1970) to 2^31 (~19 January 2038).
However, we interpret the value as an unsigned value and therefore indicate a date up to ~2075.
I don't think that's a problem.
Attachment #9018931 - Flags: feedback?(infofrommozilla) → feedback+
(In reply to Alfred Peters from comment #105)
> > Should we check 'rcvTimeSecs' before calling?
> Unixtime should be an integer with values from 0 (1 January 1970) to 2^31
> (~19 January 2038).
I meant:
if (rcvTimeSecs)
  m_newMsgHdr->SetUint32Property("dateReceived", rcvTimeSecs);

Otherwise we will actively set 1 January 1970 which is undesired. But what happens when the property is unset?

Actually, can you explain to me how the patch fixes the headline here:
  Mail date 1.1.1970(or 12.31.1969) when Date: header is localized or malformed

Didn't it default to "now" before in that case?
(In reply to Jorg K (GMT+2) from comment #106)
> > > Should we check 'rcvTimeSecs' before calling?

> if (rcvTimeSecs)
>   m_newMsgHdr->SetUint32Property("dateReceived", rcvTimeSecs);

No. Even in the old code 'rcvTimeSecs' was initialized with 0 and set in
any case.

> Otherwise we will actively set 1 January 1970 which is undesired. But what
> happens when the property is unset?

I never tested that. But we definitely don't want a random value.

> Actually, can you explain to me how the patch fixes the headline here:
>   Mail date 1.1.1970(or 12.31.1969) when Date: header is localized or
> malformed
> 
> Didn't it default to "now" before in that case?

No:

|          if (date)
|          {  // Date:
| -          PRStatus timeStatus = PR_ParseTimeString (date->value, false, &resultTime);
|            if (PR_SUCCESS == timeStatus)
| -            m_newMsgHdr->SetDate(resultTime);

SetDate() was called only if PR_ParseTimeString() was successful, ...

|          }
| -        else
| -        {  // PR_Now()

or if there was no 'date' at all.

| -          PRTime resultTime = PR_Now();
| -          m_newMsgHdr->SetDate(resultTime);
| -        }
Attachment #9018834 - Attachment is obsolete: true
Comment on attachment 9018931 [details] [diff] [review]
bug32216.patch (JK, v1)

OK, thanks for the explanations, I'll get this landed.
Attachment #9018931 - Flags: review+
Keywords: checkin-needed
Attachment #9018931 - Flags: approval-comm-esr60?
Attachment #9018931 - Flags: approval-comm-beta+
Sorry, I straightened out some white-space and added 'delivery' date back in for consistency.
Attachment #9018931 - Attachment is obsolete: true
Attachment #9018931 - Flags: approval-comm-esr60?
Attachment #9019434 - Flags: review+
Attachment #9019434 - Flags: approval-comm-esr60?
Attachment #9019434 - Flags: approval-comm-beta+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/6876e8c9ea75
If the 'Date' header is invalid, use date from 'Received' header instead. r=jorgk
Status: NEW → RESOLVED
Closed: 15 years agoLast year
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 65.0
Comment on attachment 9019434 [details] [diff] [review]
bug32216.patch (JK, v2)

Good for 60.4.
Attachment #9019434 - Flags: approval-comm-esr60? → approval-comm-esr60+
FWIW, Bugzilla currently produces email messages with "Date" headers in this format. I'm surprised that nobody found that irritating enough over the past 20 years to fix it before now. Thanks for getting to this one, folks.

From a Bugzilla message I received just this morning:

Date: =?UTF-8?Q?Fri=2C=2023=20Nov=202018=2015=3A36=3A52=20=2B0000?=
X-Bugzilla-Reason: =?UTF-8?Q?AssignedTo=20CC?=
X-Bugzilla-Type: =?UTF-8?Q?changed?=
X-Bugzilla-Watch-Reason: =?UTF-8?Q?None?=
X-Bugzilla-Severity: =?UTF-8?Q?enhancement?=
X-Bugzilla-Status: =?UTF-8?Q?ASSIGNED?=
X-Bugzilla-Priority: =?UTF-8?Q?P1?=
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: =?UTF-8?Q?bug=5Fstatus?=
[...]

Almost every single field is encoded using RFC 2047 encoded-word format.
Very strange, I see:

Date: Fri, 23 Nov 2018 15:52:34 +0000
X-Bugzilla-Reason: CC AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Classification: Components
X-Bugzilla-ID: 32216

Etc.
You need to log in before you can comment on or make changes to this bug.