Bug 68045 - User defined date acceptance patterns are used only for default language
Summary: User defined date acceptance patterns are used only for default language
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Depends on:
Blocks: Number-Format Options-Dialog-Language
  Show dependency treegraph
Reported: 2013-08-13 09:29 UTC by Petr Mladek
Modified: 2019-06-10 17:03 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Test document (test-dates,ods) (8.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-08-13 09:29 UTC, Petr Mladek

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Mladek 2013-08-13 09:29:34 UTC
Created attachment 84001 [details]
Test document (test-dates,ods)

Users might define additional date acceptance patterns in "Tools/Options/Language Settings/Languages/Date acceptance patterns". But it seems that these are used only for cells with the "default" language.

Steps to reproduce:

1. Make sure that "D/M" is listed in  "Tools/Options/Language Settings/Languages/Date acceptance patterns"
2. Open the attached "test-dates.ods"
3. Enter "14/9" in the cell [A3]

Result: The value "14/9" is saved as is.

Expected Result: The value should get interpreted as "D/M" date and saved as June 14.9.2013

Observation: The problem exists in the cell [A3] that is formatted with "Czech" language. It works as expected in the cell [B3] that is formatted with the default language.

Motivation: The problem is annoying when you need to edit documents formatted by another person and you are used to some date acceptance patterns.
Comment 1 Eike Rathke 2013-08-13 11:31:56 UTC
Date acceptance patterns are locale dependent, you'll also notice when changing the default locale in Tools->LanguageSettings that the patterns change. When a cell is formatted to a specific locale the input is expected to match that locale's definitions, this is not only the case with date but also numeric input i.e. that locale's separators are used to parse numbers. You also don't expect 1.2 being accepted as number if the decimal separator is ',' comma.

However, this is not a bug. If at all it is an RFE, but changing behavior to additionally always accept the date patterns of the default locale even for input in another locale may defeat the purpose of these patterns. Furthermore it would get hairy if the locales used the same separators but different YMD order, e.g. D/M/Y vs M/D/Y, probably the specified locale should take precedence over the default locale, but.. would users grok that? Anyhow, whatever we do here we'll never satisfy all users.