https://bugs.documentfoundation.org/show_bug.cgi?id=119739
Eike Rathke <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|x86-64 (AMD64) |All
Status|NEW |ASSIGNED
Version|6.1.0.3 release |Inherited From OOo
Assignee|[email protected] |[email protected]
|desktop.org |
--- Comment #15 from Eike Rathke <[email protected]> ---
The problem is that the column's date format is set to fixed fr-FR (French
(France)) and the field's number scanner evaluates input in the order first
work locale then format locale (NF_EVALDATEFORMAT_INTL_FORMAT), which in for
example an en-US locale leads to date acceptance patterns M/D/Y;D/M/Y so an
input of 11/12/2018 leads to M=11 and D=12, which when displayed using the
fr-FR DD/MM/YYYY date format yields 12/11/2018. An input of 23/12/2018 does not
match M/D/Y but matches D/M/Y so does not exhibit the problem.
A solution could be to swap the evaluation order
(NF_EVALDATEFORMAT_FORMAT_INTL) so input is checked against D/M/Y;M/D/Y in
order, and input matching existing values in the table's column is accepted as
is.
Another possibility could be to evaluate only against the format's locale's
patterns, but then for an empty field there's no visible indication that the
work locale's date order might not be accepted, so this is not recommendable.
There would be no problem if the field's format language was set to Default,
which follows the current work locale, and/or the ISO 8601 YYYY-MM-DD date
format was used.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
