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
