1066159 - [email] incorrect relative time shown in message list for some messages

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: wrong time.eml

Boot2Gecko 2.2.0.0-prerelease 20140910160202 on Flame, same issue on Keon 20140909

I'm in UTC+2

I got some email notifications from Mozilla's Yammer network.

Message 1 by the thread starter (attached) has been sent at UTC13:48, but the relative time delta in the message list ("x minutes ago") references UTC15:48. The notifications for the answers to these messages which had been sent at UTC14:42 and UTC14:43 use UTC15:42 and UTC15:43 for the time delta calculation.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

We use the received date of the message for sorting and display purposes, not the compose date of the message.  In IMAP this is the INTERNALDATE associated with the message which is usually the timestamp of when your SMTP server received the message but could also just be the ingestion date of the message by the IMAP server.  In contrast Thunderbird does not use (or retrieve) the INTERNALDATE.

There's definitely room for debate on whether the compose date or received date is more appropriate; I would argue for received date, but for sync purposes they are not comparable and we basically can't change this without rearchitecting all of IMAP.

The most likely explanation for what you're seeing is that yammer's internal message queue got back-logged, but also conceivable is that your IMAP server has issues or that maybe even that with our change to the email.js libs we're having parsing troubles with what it returns for INTERNALDATE.

Probably the "simplest" option to figure out what's going on is for you/me to look at the raw headers of the message.  See https://wiki.mozilla.org/Gaia/Email/ProvidingEmailsForDebugging if you need help on extracting the Received headers (I doubt you do! :), and please paste the lines here or maybe send them to me at [e-mail] and we can figure out which exactly is going on.

If the INTERNALDATE is accurate then this probably should end up as a WFM or we can ask UX what they'd prefer long-term for received versus composed.  Arguably we could do something like show "Composed at 5am but you actually received it at 3pm", especially since then it's self-explanatory why timestamps aren't lining up as one might intuitively expect, especially based on what other mail clients tend to do.

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Whoops, and you already provided the message and this is why I shouldn't respond to bugs when I'm in a rush!  Looking at the mail now...

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Okay, relevant headers:

Received: from o1.e.yammer.com ([192.254.114.132]) by mx-ha.gmx.net (mxgmx103)
 with ESMTPS (Nemesis) id 0MFigb-1XXNt624wf-00EfKP for
 <[e-mail]>; Thu, 11 Sep 2014 17:45:46 +0200
Date: Thu, 11 Sep 2014 09:48:45 -0400

Normalizing these to my time zone because that's
Received: 'Thu, 11 Sep 2014 15:45:46 GMT'
Date: 'Thu, 11 Sep 2014 13:48:45 GMT'

So this is a question of a delayed mail.

I'm interested in what you think is the reasonable thing to do here.  I'm partial to the idea of continuing to have the message list show the received date so that we continue to have a total ordering over the displayed messages, but showing both dates in the message details case when they deviate by a meaningful amount.  In which case I can file a bug and needinfo UX, etc.  Or we can use this bug too, I 'spose.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

er, and I normalized the dates to UTC but didn't update my comment.  Again, too much rushing :)

Comment 5

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

That was the first time I noticed the issue, so it likely won't happen often and can stay like it is.

Comment 6

[BMO Automation]

Firefox OS is not being worked on