Comment 50 for bug 115153

In response to Jeremy's comment #26:
> In other words, dates are a special case. I think we can extend that
> special case to the Received date as well as Date, but Order Received
> isn't a date and should probably be ordered, like all other fields,
> according to the value of the topmost thread message.

  So why is this? In what cases are sorting by the topmost thread message better than the bottommost? Admittedly, sorting by Size, or Subject, or many other things is less common, and with threading on will be very confusing anyway. If you choose to sort by Size, does Thunderbird maintain a threaded view? Presuming it does, what Size should it sort by? I would argue that Apple's "size of the thread in total" makes sense, but that might require a fair amount of additional code. And, in the case of a thread, what does define which message is "topmost" and which is "bottommost"? Order received, I assume? Mutt allows you to effectively set a secondary, thread-internal, sort, IIRC.

Ahh, I see, this is bug #262316. This changes it to be always date-based, rather than order-received-based, which just changes the problem. Especially if the GetDate that's being used by that new patch doesn't get changed to use the Received Date you're mentioning here (bug #166254).

> Ordering by Received date, I believe will do what you want. Just wait
> for that patch to be checked in and use Received date.

That would be fine. I'm happy to use Received Date instead of Order Received.

And re: comments #29-33; the fact that Thunderbird doesn't update the sort when new messages are added will still make this system very hard to use. Even with this improvement and change of configuration, which will fix the original problem at startup, if you leave Thunderbird running and receive mail on an old thread, the same problem occurs. I can accept that that's a different bug though. I'm sure it's already open more than once, if someone could place a reference here that would be useful.