Hi, (not trying to re-ignite the discussion)
i was pointed here from github, i’m just adding my 0.02€’s)
first some definitions and references, as the first question: how do others do it? was never answered.
0. the problem is inherent to the way email works: it is an unsolved(unsolveable?) problem (cfr hpk)
- there is really no such thing as a ‘sent-time’ , there only is a ‘Date:’ header.
which is under the sender’s (client) control and is easily, sometimes usefully, ‘changed’
- there are multiple received times, i.e. many 'Received: ’ headers
these actually indicate which servers the message passed through, and when.
these are reasonably accurate, trustworthy (but again there are multiple)
- FWIW: there is also the received time at the client - which is an entirely different thing.
so how does IMAP do it: AFAIK
- the server shows message in the order they are received at the imap server. i.e. the sequence number (so neither 1. 2. or 3. , but 3. gets closest as the IMAP server’s time and order should be similar and the imap server is conceptually the receiving client.
/but cfr point 0. this does not solve the ordering problem of messages in a shared chat, e.g. a chat with multiple parties on gmail and one on another smtp/imap combo will always be at risk of the gmail-crowd overtaking the others)
- the IMAP SORT specifies using the Date: header, failing that, an INTERNALDATE and then the ORDER:
As used in this document, the term "sent date" refers to the date and time from the Date: header, adjusted by time zone to normalize to UTC. For example, "31 Dec 2000 16:01:33 -0800" is equivalent to the UTC date and time of "1 Jan 2001 00:01:33 +0000". If the time zone is invalid, the date and time SHOULD be treated as UTC. If the time is also invalid, the time SHOULD be treated as 00:00:00. If there is no valid date or time, the date and time SHOULD be treated as 00:00:00 on the earliest possible date. This differs from the date-related criteria in the SEARCH command (described in [[IMAP](https://tools.ietf.org/html/rfc5256#ref-IMAP)] [section 6.4.4](https://tools.ietf.org/html/rfc5256#section-6.4.4)), which use just the date and not the time, and are not adjusted by time zone. If the sent date cannot be determined (a Date: header is missing or cannot be parsed), the INTERNALDATE for that message is used as the sent date. When comparing two sent dates that match exactly, the order in which the two messages appear in the mailbox (that is, by sequence number) is used as a tie-breaker to determine the order.
so far for the ‘how do others do it’ googling… hope that clarifies that part.
as for a solution, from the poll it seems the majority is in favour of using the Sent time.
Assuming this is from the sending client’s perspective. the closest match would be the Date: header.
As far as the hidden message problem is concerned: couldn’t this be easier solved by showing an unread/unseen indicator as is common in almost all chat apps? typically bottom right with a scroll up indicator/button? All that would be required is the DC’s version of that functionality is aware that unread messages do not come in one contiguous chunk.