127261 - Dates before the epoch (1970-01-01) not handled in nsMsgHdr::SetDate, causing invalid display in threadpane.

Status: RESOLVED WONTFIX

(MailNews Core :: Backend, defect)

Description

[odi]

An Email has (for some strange reason) headers like this:

Received: (qmail 25287 invoked from network); 21 Feb 2002 17:04:56 -0000
Received: from mta9n.bluewin.ch (195.186.1.215)
  by xxxxxxx with SMTP; 21 Feb 2002 17:04:56 -0000
Received: from [62.202.67.36] (62.202.67.36) by mta9n.bluewin.ch (Bluewin AG
6.0.040)
        id 3C5F88F8003DC3C4; Thu, 21 Feb 2002 16:31:49 +0100
User-Agent: Microsoft-Entourage/9.0.2509
Date: Thu, 07 Jan 1904 23:17:19 +0100
           ^^^^^^^^^^^
In the Inbox list the date of the email appears as: 13.02.2040 05:45

This seems strange.

Comment 1

[John Levon]

Can you reproduce with current mozilla ? please attach the email

Comment 2

[Boris 'pi' Piwinger]

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

Comment 3

[Boris 'pi' Piwinger]

Citing Boris from bug 156395 comment 1: '"1/12/1904 3:16 PM" is out of range for
the OS date-conversion functions on Windows; these overflow and return a date of
2/17/2040 11:44 PM" (which is the original date plus 2^32 ticks).'

This might be related to any of those: bug 32216, bug 73565, bug 142504

pi

Comment 4

[Boris 'pi' Piwinger]

Also happens in Linux.

pi

Comment 5

[Boris 'pi' Piwinger]

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

Comment 6

[Mike Cowperthwaite]

This appears to be a duplicate of bug 55846.  That "1904" send date seems
pretty popular.

Comment 7

[Boris 'pi' Piwinger]

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

Comment 8

[Boris 'pi' Piwinger]

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

Comment 9

[Boris 'pi' Piwinger]

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

Comment 10

[Boris 'pi' Piwinger]

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

Comment 11

[Mike Cowperthwaite]

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

Comment 12

[Frank Wein [:mcsmurf]]

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

Comment 13

[Florian Le Goff]

After some investigation, I noticed something strange with a type conversion.

When the "Date:" header is parsed, ParseTimeString returns a PRTime with the date :

> if (date)
>  PR_ParseTimeString (date->value, PR_FALSE, &resultTime);
> m_newMsgHdr->SetDate(resultTime);

But the result of this operation can be a negative value with "dates very far in the past"

> string="Tue, 06 Feb 2007 00:00:00 +0100"
> time='1170716400000000'
> string="Fri, 01 Jan 1904 23:21:42 +0100"
> time='-2082764298000000'
> string="Wed, 31 Dec 1969 23:00:00 +0100"
> time='-7200000000'

While SetDate convert it to an unsigned int for is internal storage.

> NS_IMETHODIMP nsMsgHdr::SetDate(PRTime date)
> {
>   m_date = date;
>   PRUint32 seconds;
>   PRTime2Seconds(date, &seconds);
>   return SetUInt32Column((PRUint32) seconds, m_mdb->m_dateColumnToken);
> }

Could not it be a part of the issue ?

Florian

Comment 17

[alta88]

This bug is basically invalid.  While it is clear that old dates are not handled, it is also equally true that artificially using an old date is not valid as far as publishing/sending data *in the medium* of mail or feeds, as such media did not even exist prior to the epoch.  It's an abuse of logic to claim an email was 'sent' or a feed was 'published' prior to not that long ago; these are certainly not the same as 'written' in some other format.

Comment 18

[markus-schumann]

I understand that, but nevertheless a date before 1970 is a valid rss attribute and a feed reader should handle it. why not thunderbird?
could there be any workaround? the current way is not a solution because these mails/blogposts naturally are not sent/published in 2050 but in the past.

Comment 19

[alta88]

It would be nice, and there is no question it's poorly handled, but changing this particular very old compiled unsigned int code to make it work is non trivial.  To do so for an extreme edge case, to support what is basically 'spoofing' a date, is unlikely to happen.  And spoofing or error is the only way such dates will be encountered. JMO.

Plus, the feed post you're referring to wasn't really sent in 1914 either, was it?  Nor is the published author the actual diarist, etc.

Comment 20

[Roland Hieber]

Attachment: Date column vs. date in message view

While it might be a valid reason not to touch very old code to handle an edge case, I might add that the date is displayed correctly in the message pane (see attached screenshot). Additionally, we might encounter this bug again in a few years, see #387387 ;-)

Comment 21

[alta88]

;)

Sure because the headers are retrieved/mimeparsed by a different code path for message display, while the threadpane has a very different presentation internally.  Its folder db/memory contains all the dates.  The value isn't kept as PRTime, a 64bit signed int, is but converted to a 32bit unsigned int.  Maybe because 32 is 1/2 64, perhaps it has to do with sorting efficiency, maybe because it's overkill for legitimate dates for the foreseen life of the software.

As for bug 387387 and future dates, 2038 is fine but 2106 is a problem.  Not like 3°, but a problem..

Comment 22

[Hartmut Welpmann [:welpy-cw]]

Risk-reward-ratio for fixing this is really high I'd say.