https://bugs.documentfoundation.org/show_bug.cgi?id=149950
Eike Rathke <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|LibreOffice |framework Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|[email protected] |[email protected] |desktop.org | --- Comment #6 from Eike Rathke <[email protected]> --- In the description you wrote > My language setting is "English (South Africa)" and the default data > recognition strings are "Y-M-D;Y/M/D;M-D;M/D". This does not include "D M > Y", but LibreOffice seems to recognise the format anyway. which I could not confirm. With 'D M Y' added of course "02 03 2020" is recognized. Anyway, the date acceptance patterns determine which numeric date inputs are to be accepted and adding 'D M Y' should not be necessary. Long date inputs with month names have additional logic respecting the locale's long date separators and spaces. That so far works but then feeding the detected values to the calendar goes wrong because the long date DMY order does not match the numeric date YMD order and determining the difference apparently has a bug, so the calendar is fed with year:=2, month:=3, day:=2020; which of course is invalid. This is no problem in the en-US locale because both, numeric and long date, have a MDY order, or other locales that for long date and numeric date have the same DMY or YMD order. -- You are receiving this mail because: You are the assignee for the bug.
