View Single Post
Old 11-08-2011, 02:30 PM   #2
chaley
Grand Sorcerer
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: 11,728
Karma: 6690881
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
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
chaley is offline   Reply With Quote