View Single Post
Old 11-08-2011, 03:30 PM   #2
chaley
"chaley", not "charley"
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 5,817
Karma: 1216136
Join Date: Jan 2010
Location: France
Device: Many android devices
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 03:53 PM. Reason: fix typo pointed out by starson17
chaley is offline   Reply With Quote