Comment 19 for bug 803806

The data is fetched from the DB in get_recent_changes(), which sorts the results by the date of the CHAN record (but not the time).

Then, in print_changes_list(), we populate the ['jd'] field with $n. This simply maintains the sort order, as the original $jd value is no longer available.

Then, to sort by date, we use event_sort() - which sorts by the ['jd'] value.

This sort is, I guess, redundant. We simply want to maintain the original sort order, as it was sorted by the database.

We only need to apply a secondary sort if the user has selected "sort by name".

I can see how this might get the *time* portion of the sort wrong, but not the *date*. This was the point I made right at the begninning in post #2.

You have been me that the *date* is wrong, and
(a) you have not provided an example
(b) it doesn't happen for me
(c) I can't see from the code how this would be possible

But, if this is the case (date correct, time incorrect), then a better fix is surely something like fetching the list of changes from the wt_change table (which has a timestamp) instead of the wt_date table (which has only a date).

This is why I am keen to understand the actual problem.