View Single Post
Old 04-10-2010, 05:46 AM   #27
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: 12,476
Karma: 8025702
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kovidgoyal View Post
@chaley: IIRC, the implementation uses parse_date. In which case it will parse a rather wide range of date specifications.
Yes it does use parse_date, which (as you are implying) means that it will make educated guesses about the date. Unfortunately, the guessing does not use the locale, so ambiguous dates are parsed as m-d-y. For example, entering 5-1-10 will result in 1 June 2010 even if the locale specifies d-m-y. This is the behavior for parsing all dates in calibre, which may or may not be a bug (I don't know).

Other than the above locale issue, the current implementation has two problems. The first is that to implement partial matching, the code must know what the date segment separator is. Currently it accepts only '-'. I will change this to accept '-' or '/' (any others?). The second is that using guessable formats will be far more likely to throw a value exception, and these currently are badly (i.e., not) handled. I will fix this as well.
chaley is offline   Reply With Quote