Deltachat-android: time sent: display date if deviating

[testbird]

The "time sent" is now displayed correctly (https://github.com/deltachat/deltachat-core/commit/9f4ab2fd876b623a23666522d095cfa3da126664).

But when some messages are delayed or only downloaded after some offline-days, they look as if they where from the current day (and even right out of the future, if sent later in the day).

It seems ok to display the messages in the order as arrived but confusing situations could be avoided, if the true date (day) could also be displayed in case it is different than the current date (as indicated by the markers in message list).

[r10s]

took me a moment to understand.

so you want to display _day/month/year_ beside the time if the arrival time is on another _day/month/year_ as the sending time. yes, this sounds reasonable. however, as an workaround, currently, the whole times for such cornercases can be viewed at "info".

not sure if my explanation makes things clearer :)

[testbird]

Yes, it's clearer to print the date within the messages, if they are from another day. As they appear in the list as if they were sent on the current day, this can lead to funny confusions. Or make senders look strangely repetitive or inadequate. ;-)

[r10s]

i agree, this should be optimized sooner or later.

[r10s]

this is an android-issue, there's nothing the core can do about this.

however, iirc, the upcoming android version from https://github.com/deltachat/deltachat-android-ii/ will have the date visible in a non-scrolling area permanently (as signal or newer versions of telegram - don't know whatsapp)

[testbird]

Why can't the core add the date at which a messages was sent (e.g. Aug. 20) to the received message, if it predates the date on which the message was received (today is Aug. 28)?

That would make it visible that the message got delayed, is old, sent in the past.

[r10s]

the core always returns _full sending date+time_ for every message, it's the UI that formats the timestamp and decides eg. only to display the time, to display sth. like "minutes ago" or whatever.

[testbird]

Ah ok,

But if moving issues is not possible, all the issues should only be closed if actually solved in the new frontend, to ensure that they are not dropped.

[testbird]

Actually, the core could insert [Message from: Aug. 20th] to make an older date sent known.
The new android frontend's date visualization won't help if it only shows the received at date (the message sorting value).

[r10s]

yes, letting the core add sth. like [Message from: Aug. 20th] is probably a good idea solution. however, still believing this is better handled by the ui.

[r10s]

cool - github finally allows transferring issues :)

[angelo-fuchs]

Letting the core add something like this is probably a solution, but I'd much rather fix that in UI.

[r10s]

jupp, i also would not like that in the core.
however, i think this is currently one of the less important issues, so i would not target this now.