|
I understand what you want to do, and I think I answered the question on your other post. I am not totally convinced that the behavior you want is correct, but I am willing to go along with it. Reason for doubt: looking at a subset of the information does not always mean that it should sort that way. For example, consider a net-worth column. Should it sort by pennies because that is what I am looking at, or should it respect the 'real' net worth? Arguments exist on both sides.
Also, sorting the {date} column does sort as a date-time. The parts that are not shown are set to some default, which depending on the template may cause the sort to behave as you want.
As I said, I am willing to go with the 'sort by what I see' position if Kovid is. Repeating that other post here for completeness: I have an implementation that sorts dates as displayed. The performance penalty is not huge. For a 20,000 book library, the time to sort by a date column went from approximately 1/2 second to 1 second, or some 500 microseconds per book. This is consistent with my mark 1 eyeball estimate of the cost of trimming the date.
[...]
One note: the sort will respect strange display templates and do something. If your display template is, for example yyyy/ss, then the month, day, hour, and minute will be filled in with a constant. The results could easily not be what you expect. Continuing the example, 2011/10/25 19:08:10 and 2011/01/19 10:10:10 will sort as equal because the years (2011) and the seconds (10) match.
|