Created attachment 144725 [details] Table with Date field I have Interface language English I have local settings put to French(France). When I fill in dates in a date column of a table in base the format applied once I loose focus of the date fields is wrong. In attachment I have put in Table1 a date 11/12/2018. It is changed automatically to 12/11/2018.
Have tested with interface language German. Field is formatted for French, as you described. Written 11/12/2018 in the field > next row > 11/12/2018 is saved. My system: OpenSUSE 15, 64bit rpm Linux, LO 6.1.0.3 So I couldn't confirm the buggy behaviour.
My system : Linux Mint 18 Cinnamon 64-bit LibreOffice: 6.1.0.3
OS = Ubuntu 18.04 OS/LibreOffice = English Open that table and enter a new record with the date: 12/15/2018 Enter that and it is changed to 15/12/2018 Which is what you want it to do, right, that is the French format?
It is still a problem. I should be able to put 6th of September 2018 in french format (06/09/2018). When I put this date it is immediately converted into 09/06/18 (9th June 2018). (06/09/2018) should remain as is. Same problem occurs on Microsoft Windows 7 enterprise 64-bit.
Confirming with Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded I can reproduce this with ambiguous day/month sequences, e.g: 2nd June 2017 or 2nd April 2019. If I type in 02/06/2017, LO displays 06/02/2017 If I type in 02/04/2019, LO displays 04/02/2019 Note that both the system locale at the OS level, and the LO locate setting are set to FR. Only the LO-UI is set to US.
@Eike : any insight into why this might happen ?
If I switch the UI back to FR, then dates that I enter using the DD/MM/YYYY format are displayed correctly in the table.
(In reply to Alex Thurgood from comment #5) > Note that both the system locale at the OS level, and the LO locate setting > are set to FR. Only the LO-UI is set to US. Also, the date recognition pattern is set to D/M/Y; D/M; D.M.Y; D-M-Y which in theory should mean that irrespective of the LO-UI language, dates that I enter as DD/MM/YYYY should be displayed as such.
Sounds like Base wrongly derives the locale from the UI locale instead of the work locale.
I tested with LibreOffice UI locale set to English, LibreOffice locale setting set to English. Could not reproduce. I enter 12/11, I get 12 November. I enter 11/12, I get 11 December. I enter 02/06, I get 2 June. Tested also with with LibreOffice locale set to "Default - English (UK)", same result. My system locale settings are: LANG=en_GB.utf8 LANGUAGE= LC_ALL= LibreOffice 6.1.0.3, Debian package, Build ID: 1:6.1.0-1
The problem occurs when Interface language is set to : English local settings is set to : French(France) As mentionned there is a format problem due to a difference between "Interface language" and "local settings". Dates like 09/06/2018 are inverted 06/09/2018 When 13/06/2018 is put then system recognizes that 06/13/2018 is logically invalid for format DD/MM/YYYY. 13 > 12 months. I hope it is clearer.
(In reply to Lionel Elie Mamane from comment #10) > I tested with LibreOffice UI locale set to English, LibreOffice locale > setting set to English. That was a typo. I meant "LibreOffice locale set to French". Maybe the system locale plays a role?
FWIW, my system locale is: LANG=fr_FR.UTF-8 LANGUAGE = LC_ALL =
My system locale is : LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC=de_BE.UTF-8 LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY=de_BE.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=de_BE.UTF-8 LC_NAME=de_BE.UTF-8 LC_ADDRESS=de_BE.UTF-8 LC_TELEPHONE=de_BE.UTF-8 LC_MEASUREMENT=de_BE.UTF-8 LC_IDENTIFICATION=de_BE.UTF-8 LC_ALL= I hope this can help
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.
There must be some additional quirk which kicks in when the work locale is set to fr-FR as per comment 11, which should match the fr-FR date format but apparently does not.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e30f6a8c6b053e7a7b9c54fb3fdaed4e73bb5389 tdf#119739 split ConfigManager::getLocale(), getUILocale(), getWorkLocale() It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=da4dc534403b74182913cc4dfeb2b689a30e513c Resolves: tdf#119739 switch date field input to NF_EVALDATEFORMAT_FORMAT_INTL It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.