Bug 4059 - Sort by date works incorrectly
Summary: Sort by date works incorrectly
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI/Message List (show other bugs)
Version: 3.17.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-07-19 11:39 UTC by George
Modified: 2018-07-22 14:19 UTC (History)
0 users

See Also:


Attachments
screenshot of first folder (31.61 KB, image/png)
2018-07-19 11:39 UTC, George
no flags Details
screenshot of second folder (after the move) (31.39 KB, image/png)
2018-07-19 11:40 UTC, George
no flags Details

Description George 2018-07-19 11:39:45 UTC
Created attachment 1894 [details]
screenshot of first folder

version 3.16.0git241

STR:

1. Send a message to myself (test 1)
2. Receive the message
3. Repeat 1-2 (test 2)
4. Mark sent messages in black and received in red and put them in the same folder
5. Make sure sorting is by date

EXPECTED:

test 1 - black
test 1 - red
test 2 - black
test 2 - red

ACTUAL:

test 1 - black
test 1 - red
test 2 - red
test 2 - black

i.e. for test 2 the received message appears before the sent one (incorrect).

7. Move all 4 messages to a new empty folder

EXPECTED:

(same as above). Additionally I expect at least the wrong actual sorting to be preserved.

ACTUAL:

test 1 - red
test 1 - black
test 2 - black
test 2 - red

i.e. the order has changed and now for test 1 the sent message shows before the received one (incorrect) and for test 2 the sorting is correct.

Additionally: the attachment icons on red messages are missing (mentioned in bug#3307)
Comment 1 George 2018-07-19 11:40:27 UTC
Created attachment 1895 [details]
screenshot of second folder (after the move)
Comment 2 George 2018-07-19 11:41:45 UTC
Note: moving messages back to the first folder restores the sorting:

test 1 - black
test 1 - red
test 2 - red
test 2 - black
Comment 3 Shai Berger 2018-07-21 20:02:46 UTC
I'd expect sorting of messages by date within a folder to be based only on the date field of the message itself. Given that the red/black pairs are really copies of the same message (with the same date value), I see no reason whatsoever why Claws Mail should prefer any order within such a pair.

Or, looking at it another way: You suggest that, when sorting messages with equal date field values, some constraints should be placed on the sort order (either some additional data, like the order in which the messages showed up in the client, or preserving the order when moving between folders). This would be an "enhancement", but one which I, at least, would object to, as such constraints could make the sorting in general slower, and the situation they improve is, in my view, a fringe use-case.
Comment 4 George 2018-07-21 20:45:22 UTC
> Given that the red/black pairs are really copies of
> the same message (with the same date value), I see
> no reason whatsoever why Claws Mail should prefer
> any order within such a pair.

Also there is no reason why CM should prefer showing
an event in the future (received message) before an
event happened in the past (sent message) or changing
that by just moving the pair to another folder.

> Or, looking at it another way: You suggest that,
> when sorting messages with equal date field values,
> some constraints should be placed on the sort order
> (either some additional data, like the order in
> which the messages showed up in the client, or
> preserving the order when moving between folders).

I don't know what is the proper way to fix this.

> This would be an "enhancement", but one which I, at
> least, would object to, as such constraints could
> make the sorting in general slower, and the
> situation they improve is, in my view, a fringe
> use-case.

Well, it can be argued that achieving a quick but
wrong result is not really a gain. And of course you
can argue back that sorting a message sent to oneself
doesn't have any value as it is unusual and would
never be an actual issue.  But the fact remains - the
sorting is wrong, so I thought I should report it.
Comment 5 Shai Berger 2018-07-21 21:44:25 UTC
(In reply to comment #4)
> > Given that the red/black pairs are really copies of
> > the same message (with the same date value), I see
> > no reason whatsoever why Claws Mail should prefer
> > any order within such a pair.
> 
> Also there is no reason why CM should prefer showing
> an event in the future (received message) before an
> event happened in the past (sent message) or changing
> that by just moving the pair to another folder.
> 

I must have been unclear in my earlier comment.

When I said "I see no reason whatsoever why Claws Mail should prefer any order within such a pair", I meant that either order is OK and CM should be free to pick the order it sees fit.


> 
> Well, it can be argued that achieving a quick but
> wrong result is not really a gain.

My point, to be perfectly clear: The results you have seen are not wrong.

To explain it even more: Suppose I send you a message at 14:00, but for some reason, it takes two hours to arrive. I also send you another message at 15:00, and for some (other) reason, that one takes only two minutes to arrive. When you have received both messages, and sort the folder by date, the 14:00 message should show first, although it arrived later -- because it is dated earlier. "Sorting by date" should not take into account the order of network events, but just the date as it shows in the message.

And thus, if you have two messages with the exact same date (like in your examples), you should not expect any specific ordering between them.
Comment 6 George 2018-07-22 08:15:47 UTC
> When I said "I see no reason whatsoever why Claws
> Mail should prefer any order within such a pair", I
> meant that either order is OK and CM should be free
> to pick the order it sees fit.

I know what you meant but it is still wrong. CM should
not "be free" but should do what we need = correct
sorting. How exactly this should be achieved - I really
don't know but it is wrong to see a future event
appear earlier than a past one. Whether it would be a
matter of involving additional checks in the sorting
algorithm or something else on the computer side, the
human expectation is that the past is before the
future. Expecting the user to be an expert who would
understand why things work wrongly and based on that
accept the wrong behavior is also a wrong expectation.

I hope that clarifies.

> My point, to be perfectly clear: The results you
> have seen are not wrong.

Based on what was explained and demonstrated: Not only
they are wrong but also inconsistent.

> To explain it even more: [...] if you have two
> messages with the exact same date (like in your
> examples), you should not expect any specific
> ordering between them.

I understand your logic but it still doesn't explain
the inconsistency observed when moving the message
pairs between different folders.
Comment 7 Paul 2018-07-22 09:17:14 UTC
the pairs of messages have the same date, both orders are correct.
Comment 8 George 2018-07-22 09:32:31 UTC
Paul,

Why is there inconsistency when moving between folders?
And what determines which message with the same date should be before the other?
Comment 9 Richard 2018-07-22 14:19:34 UTC
I don't see anything about this that is odd or "wrong". In the world of record retrieval, records are selected and the output ordered, by the criteria provided. If the criteria match exactly across all the retrieved records the output order is generally referred to as "arbitrary", and is determined by deeper issues. In the case of a database, it's often record id or index order. With files it's generally inode. This means that if you copy records/files from one location to another these lower-level items will likely change, so the output order will change too. So, if you have 2 or more records where the user-visible Date: (message creation date/time) field is identical, and that's the field you are selecting and sorting on, then the output order is what it is and may well be different if the same messages are moved to a different location. With a database, the output can well vary from one record retrieval and display to the next due to underlying index optimization.

I have often wished that I could use more than one criteria for the sort of records on output (something that is basic to true database output), but these types of displays, which are common across most current UIs of all types, don't support that. It would be a nice enhancement.

Note You need to log in before you can comment on or make changes to this bug.