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.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.