Currently, in some situations, sorting images by date (either by "updated date" or "created date") can produce orderings that are different from those produced by normal file managers. The issue is that the sorting is performed on the date and created_time strings which are obtained by formatting the true timestamps using the %Y-%m-%d %H:%M:%S pattern.

The problem is that when timestamps are really close together or even identical (!), the order becomes essentially random. This is especially noticeable when performing batch copy/move operations on files. In that case, the difference between timestamps ends up being on the order of milli/micro/nano-seconds and so the order of display in local file managers / image viewers ends up drastically different from the order in iib.

This can be improved a bit by adding a .%f to the end of the timestamp formatting pattern, but this is kind of a hacky solution, because the date and created_time fields are currently also used for display purposes. It's better to keep these "display" timestamp string fields and add extra fields for storing the "raw" timestamps as floats (or even better - as integer counts of nanoseconds as provided by st_mtime_ns/st_ctime_ns).

Additionally, I think that the sorting logic should explicitly handle the case where the timestamps are exactly equal and allow the user to select how to break the ties (by choosing "name ascending" or "name descending" as a secondary key since those two orders are the only ones that guarantee uniqueness).