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

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[Christophe Veber]

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.

Comment 1

[Katsuhiko Momoi]

Someone, please check this out and confirm this bug. I can't do it
until Monday.

Comment 2

[nhottanscp]

>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 <[e-mail]>
X-Mailer: Mozilla 4.7 [ja] (Win98; I)

cc to rhp, putterman, ducarroz.

Comment 3

[nhottanscp]

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.

Comment 4

[bobj]

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?

Comment 5

[ji]

Yes, the thread pane can display localized date format.

Comment 6

[Christophe Veber]

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

Comment 7

[bobj]

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?

Comment 8

[Christophe Veber]

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.

Comment 9

[bobj]

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.

Comment 10

[Christophe Veber]

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

Comment 11

[nhottanscp]

> Outlook (Express), KMail and XFMail properly sorted mails with non-standard 
> Date: tags.
Are they also display the dates properly?

Comment 12

[bobj]

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.

Comment 13

[Christophe Veber]

Outlook, etc., also display the date properly.

Comment 14

[nhottanscp]

One more question, does outlook seem to be using the server time stamp or 
interpreting the localized date?

Comment 15

[Christophe Veber]

Attachment: sample localized header

Comment 16

[Christophe Veber]

Outlook seems to use the server time stamp.

Comment 17

[bobj]

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?

Comment 18

[Christophe Veber]

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.

Comment 19

[bobj]

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.

Comment 20

[nhottanscp]

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).

Comment 21

[Jean-Francois Ducarroz]

Reassign to rhp

Comment 22

[Jean-Francois Ducarroz]

This time is really reassigned!

Comment 23

[rhp (gone)]

I think this is working for me...I tried the attached message and it looks 
correct. Possibly someone can verify.

- rhp

Comment 24

[Katsuhiko Momoi]

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.

Comment 25

[marina]

i am verifying it as wfm ( reporter can add comments if he still has a problem)

Comment 26

[Christophe Veber]

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

Comment 27

[marina]

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. 

Comment 28

[marina]

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.

Comment 29

[Christophe Veber]

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.

Comment 30

[marina]

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. 

Comment 31

[Christophe Veber]

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.

Comment 32

[marina]

<How will you solve this?
Cristophe, please read comments #17 from bobj, especially (3) that he favors for
malformed headers.

Comment 33

[Christophe Veber]

OK, (when) will this issue be solved?

Comment 34

[scottputterman]

reassigning to ducarroz

Comment 35

[Jean-Francois Ducarroz]

Really reassign to me...

Comment 36

[marina]

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

Comment 37

[scottputterman]

I don't think we're going to be doing this any time soon.  Renominating for
reconsideration by triage team.

Comment 38

[Michael Buckland]

Discussed in 2/25 bug meeting with Mktng, PjM, Engineering.  Decision to minus
and future.

Comment 39

[Shoshannah Forbes]

related to bug 131983?

Comment 40

[Christophe Veber]

Don't think so. Date: tag in  bug 131983 looks OK and _not_ localized.
Christophe Veber

Comment 41

[Russell Odom]

Can someone take a look at bug 132779 and dupe it to this if it looks similar
enough?

Comment 42

[marina]

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?

Comment 43

[marina]

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

Comment 44

[Igor Velkov]

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 <[e-mail]>; 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$[e-mail]>
From: "Aleksandrs Volperts" <[e-mail]>
To: "Igor Velkov" <[e-mail]>, "tink" <[e-mail]>
References: <[e-mail]>
<[e-mail]> <[e-mail]>
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 годом. Никаких проблем с ними не было.

Comment 45

[nhottanscp]

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.

Comment 46

[Boris 'pi' Piwinger]

*** Bug 142504 has been marked as a duplicate of this bug. ***

Comment 47

[Peter Woo]

Attachment: date-since-1900 format at DATE: tag

Comment 48

[Peter Woo]

It seems that there is another strange format of date-since-1900 in use.  Have
attached a sample.
Thks.

Comment 49

[Christophe Veber]

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?

Comment 50

[Frank Tang]

could someone summarized a list of mailer which will produce these localized
date in the RFC822 headers?

Comment 51

[J Luh]

Bug 73565 may be a duplicate.

Comment 52

[R.K.Aa.]

*** Bug 180254 has been marked as a duplicate of this bug. ***

Comment 53

[Christophe Veber]

Frank Tang: Do you want to assess the relevance of the flaw or do you want a
mailer that creates malformed Date: tags?

Comment 54

[Simon Montagu :smontagu]

simon will take a look at this bug and summarize it to see where the problem
arises specifically. 

Comment 55

[Christophe Veber]

Attachment: Mini mail app that send localized (german) Date: tag; Win32

Win32 app that sends german localized Date: tag.
The program can be used to see if Netscape mailer behaves correctly.

Comment 56

[Christophe Veber]

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.

Comment 57

[Peter Woo]

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?

Comment 58

[Christophe Veber]

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 !

Comment 59

[scottputterman]

reassigning to smontagu and marking nsbeta1+ per mcarlson

Comment 60

[Christophe Veber]

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

Comment 61

[Samir Gehani]

i18n triage team: nsbeta1-

Comment 62

[Nigel Weatherby]

Attachment: another example of a incorrectly handled date format

date time was displayed as 06/02/2101 06:28 

it was actually 01 dec 2003 13:20:06

Comment 63

[WADA:World Anti-bad-Duping Agency]

Set Bug 73565 as "Depends on:" of this bug, which is bug for "No Date: header" case.

Comment 64

[Matthias Versen [:Matti]]

*** Bug 288681 has been marked as a duplicate of this bug. ***

Comment 65

[Matthias Versen [:Matti]]

*** Bug 293252 has been marked as a duplicate of this bug. ***

Comment 66

[Matthias Versen [:Matti]]

*** Bug 293515 has been marked as a duplicate of this bug. ***

Comment 67

[Frank Wein [:mcsmurf]]

*** Bug 300832 has been marked as a duplicate of this bug. ***

Comment 68

[Christophe Veber]

works with Firebird Version 1.0.6 (20050716).

Nice to see that - but: what this fix intentional?

Comment 69

[Alexander Skwar]

(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"?

Comment 70

[Christophe Veber]

Sorry - I mixed it up: I meant Thunderbird, of course.

Comment 71

[Jason Bassford]

I don't see any evidence of a patch that was checked in or reference to another
specific bug that fixed this.

-> WORKSFORME

Comment 72

[Christophe Veber]

who will verify/close this?

Comment 73

[Charles E. Hill]

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)

Comment 74

[WADA:World Anti-bad-Duping Agency]

(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? 

Comment 75

[WADA:World Anti-bad-Duping Agency]

Christophe Veber, do you set mailnews.display.original_date to true?

Comment 76

[Christophe Veber]

Attachment: Wrong Date: tag - correct in Thunderbird

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)

Comment 77

[Christophe Veber]

for comment #75:
No, the setting is
...
pref("mailnews.display.original_date", false);   // display date string from
mail headers without interpreting
...

Comment 78

[WADA:World Anti-bad-Duping Agency]

(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.

Comment 79

[Christophe Veber]

cf comment #78

Comment 80

[ynik]

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.

Comment 81

[WADA:World Anti-bad-Duping Agency]

Changing conmonent from "MaiNews: Internationalization" to "MailNews: MIME",
because "malformed Date: header" handling problem.

Comment 82

[WADA:World Anti-bad-Duping Agency]

Reassigning to default bug owner due to component change.

Comment 83

[WADA:World Anti-bad-Duping Agency]

At last, David has started to care on "No Date: header" case in Bug 166254.

Comment 84

[Boris Zbarsky [:bzbarsky]]

*** Bug 299114 has been marked as a duplicate of this bug. ***

Comment 85

[Magnus Melin [:mkmelin]]

*** Bug 295208 has been marked as a duplicate of this bug. ***

Comment 86

[Magnus Melin [:mkmelin]]

*** Bug 364584 has been marked as a duplicate of this bug. ***

Comment 87

[WADA:World Anti-bad-Duping Agency]

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.

Comment 89

[WADA:World Anti-bad-Duping Agency]

mailnews.use_received_date was unfortunately landed on Tb2, but it removed from Tb3. Tb3 introduced "Received" column unstead. See bug 166254.

Comment 92

[Michael Lueck]

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.

Comment 93

[Michael Lueck]

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*

Comment 95

[Peter]

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?

Comment 96

[Joshua Cranmer [:jcranmer]]

(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.

Comment 97

[Mason]

(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

Comment 98

[Mason]

Turns out Peter's issue has already been discussed in bug 276199
(RFC-2047-encoded Date header not parsed or displayed correctly)
=> RESOLVED INVALID

Comment 99

[Craig Emery]

I've got a date header as

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

that shows up as 01/01/1970 00:00

Comment 100

[Mason]

(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 101

[Alfred Peters [:infofrommozilla]]

Attachment: If the 'Date' header is invalid, use date from 'Received' header instead.

Comment 102

[Alfred Peters [:infofrommozilla]]

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.

Comment 103

[Alfred Peters [:infofrommozilla]]

(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)

Comment 104

[Jorg K (CEST = GMT+2)]

Attachment: bug32216.patch (JK, v1)

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);

Comment 105

[Alfred Peters [:infofrommozilla]]

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.

Comment 106

[Jorg K (CEST = GMT+2)]

(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?

Comment 107

[Alfred Peters [:infofrommozilla]]

(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);
| -        }

Comment 108

[Jorg K (CEST = GMT+2)]

Comment on attachment 9018931 [details] [diff] [review]
bug32216.patch (JK, v1)

OK, thanks for the explanations, I'll get this landed.

Comment 109

[Jorg K (CEST = GMT+2)]

Attachment: bug32216.patch (JK, v2)

Sorry, I straightened out some white-space and added 'delivery' date back in for consistency.

Comment 110

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6876e8c9ea75
If the 'Date' header is invalid, use date from 'Received' header instead. r=jorgk

Comment 111

[Jorg K (CEST = GMT+2)]

Beta (TB 64):
https://hg.mozilla.org/releases/comm-beta/rev/6e8c0cff670e

Comment 112

[Jorg K (CEST = GMT+2)]

Comment on attachment 9019434 [details] [diff] [review]
bug32216.patch (JK, v2)

Good for 60.4.

Comment 113

[Jorg K (CEST = GMT+2)]

TB 60.3.2/60.4 ESR:
https://hg.mozilla.org/releases/comm-esr60/rev/b02fba3200f5c14b88dcb672fc9fd4aa8c3b8083

Comment 114

[Christopher Schultz]

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.

Comment 115

[Jorg K (CEST = GMT+2)]

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.