https://bugs.freedesktop.org/show_bug.cgi?id=59978
Lionel Elie Mamane <lio...@mamane.lu> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |All OS|Mac OS X (All) |All Summary|EDITING: Query-Wizard could |EDITING: Query-Wizard |not search by Date (Mac OS |locale/date-format mixup |X) | --- Comment #18 from Lionel Elie Mamane <lio...@mamane.lu> --- Reproduced on Debian GNU/Linux master commit ba26c5e6330f5f1f38aab698b2b2c32cac7b5df3 (Mon May 13 08:24:49 2013 +0200). The reason is "simply" that different parts of the wizard disagree on the locale and thus on the date format... Which means that you will not see the problem in a fully en-US locale (or any locale that has mm/dd/yyyy date-format). 1) The 'search conditions' step "clearly" uses a en_US locale; it expects the date as mm/dd/(yy)yy. In this bug's example, it displays the value as 06/30/52. 2) The 'Overview' step uses the user's locale, in my case fr_LU; Search conditions: DATENAISSANCE is equal to #30/06/1952# (not sure that's a good idea... aren't #DATE# strings supposed to be the MS-Access compatible "fixed" format mm/dd/yyyy?) 3) But when one clicks on "Finish", the SQL parser launched on the string "#30/06/1952#" is created without context, and thus defaults to en_US, and fails to parse that date because there is no month "30", only 1 to 12. By the way, second bug: the entered date in 'seach condition' step is formatted as mm/dd/yy, and then the century is LOST!!! Type 1/1/1515, it will understand 1/1/15, that is 1/1/2015. Sigh... -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs