Regarding your post in the date-changed thread: 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.
Next step is for Kovid to look at it. I might have done something stupid, he might have some suggestions for improvement, or he might object to the principle for a reason I haven't thought of.
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.
Last edited by chaley; 11-08-2011 at 02:53 PM.
Reason: fix typo pointed out by starson17
|