RFC: sort 'dive number' column by date, not number

[Linus Torvalds]

Ok, so this sounds insane, but it fixes our currently broken sorting
of dive trips vs plain dives not in trips.

The reason for that is simple: the dive trips are sorted by date, but
that's column #0, and for plain dives is the dive number.

So currently the trip-vs-dive sorting looks at the date of the trip,
and compares that to the number of the dive. Since the date of the
trip is expressed as seconds-since-1970-in-UTC, unsurprisingly the
dive number is generally much smaller (even for some very avid divers
;), and so the plain dives end up sorting way at the bottom (or at the
top, if you do "oldest trips first"

Since the dive number *should* sort as the date, this stupid attached
patch just makes us return the dive date instead.

Now, there are other possible solutions to this:

 - make the date of the dive be column 0, and make the dive number be column 1.

   Quite frankly, while more logical for this particular problem, it
probably sucks as a solution. We do want to have a column we can sort
dives by that is date-based, but doesn't include trips. And while the
dive number *should* sort identically to the date one, the fact is
that you can have dives without any numbering, so it doesn't.

   In contrast, all dives have dates, and sorting numbered dives by
date should still result in sane behavior (and if it doesn't, then the
insanity comes from the dive numbering, and odd sorting is the fault
of the user and indicative of a problem)

 - We could possibly do something magical like sorting dives by number
when they are inside trips, or when no trips exist at all. But then
we'd sort by date when there are trips and the dive is outside the
trip. But quite frankly, that just sounds insane.

So on the whole, I don't love this patch, but it seems to be the least
confusing of the possibilities.

Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
---

Hmm? Any other ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 580 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130608/f36a3e62/attachment.obj>