Created attachment 64259 [details]
example for date
the local date format (german) converts the date to the american format only in 22.214.171.124
no problems in 3.5.5
Hm, with german localization I expect exactly the behavior you complain in your document: Here input 17-07-12 Is the short form of 2017-07-12 what means 2012-July-12
I doubt that we have a real bug, believe that it's a settings 7 defaults problem.
I am pretty sure that reporter's beta1 uses a (dev) user profile different from the normal release user profile, what might cause different settings. Date input can be worrying, see
– if possible contribute an instruction how to create a sample document
from the scratch
- add information
-- what EXACTLY is unexpected
-- and WHY do you believe it's unexpected (Localization settings)
-- concerning your PC
-- concerning your OS (Version, Distribution, Language)
-- concerning your LibO localization (UI language, Locale setting)
–- Libo settings that might be related to your problems
-- how you launch LibO and how you opened the sample document
–- Your results after having copied your "normal" user profile to the
dev-Profile used by beta1
-- All localization info available (OS, LibO settings, ...)
-- your Styles settings for dates
-- everything else crossing your mind after you read linked texts
how to see the bug:
OS WIN 7 64 location Germany, german locales, tested with 126.96.36.199 with German dialogs same with the actual nightly build with English dialogs.
create a new empty calc sheet
write 16-07-12 into one of the cells, date of today in german notation
the cell now contains: 2012-07-16
i would expect 16-07-2012 german date format.
write 27-07-12 date at end of this month in german notation
now appears 2027-07-12
seems that there not only a turn of the date.
in calc "the type enter to edit" setting in options is set.
thank you for prompt responding
I saw that you had the same observation in "Bug 52240 - EDITING: Incomplete Date values are no longer detected". For me reporter's results are not unexpected (see Comments above), but currently I don not have enogu info (lack of time) to understand all aspects of a possible bug. May be you can assist?
i just tested with version 188.8.131.52 with win 7-64:
the problem still exists.
as a result you cannot work with dates and calc in a country that sets day-month-year (as in germany). Inputs became in best case year-month-date.
i think this is a serious bug that can change user inputs unexpectedly.
theems that a local set in calc isnt used.
19.7.2012 thank you gerdl
Please cite a DIN or ISO for your hypothesis that "day-month-year" is a german date format. I doubt! It is not correct to believe simply that that exists because we also have "day.month.year".
(In reply to comment #3)
> @Johannes Weberhofer:
> I saw that you had the same observation in "Bug 52240 - EDITING: Incomplete
> Date values are no longer detected". For me reporter's results are not
> unexpected (see Comments above), but currently I don not have enogu info (lack
> of time) to understand all aspects of a possible bug. May be you can assist?
I have added a comment in the mentioned bug
(In reply to comment #2)
> write 16-07-12 into one of the cells, date of today in german notation
No, that is not a German date notation. German date notation would be 16.07.12
> type enter
> the cell now contains: 2012-07-16
> i would expect 16-07-2012 german date format.
> write 27-07-12 date at end of this month in german notation
> type enter
> now appears 2027-07-12
27-07-12 is an abbreviated DIN 5008 / ISO 8601 notation (and actually wrong because ambiguous in this case, maybe we should even not accept that), and there the date order is Y-M-D, see also DIN 5008 http://www.din-5008-richtlinien.de/datum.php and https://de.wikipedia.org/wiki/Datumsformat
To accept 27-07-12 as 27.7.2012 in the german locale is only good for usability: There is no dot at the numerical keyboard, so the only way to type dates fast is to use one of the available signs on the keyboard.
I also think it's important to keep that compatible with old version and MS software...
implements user editable date acceptance patterns under Tools->Options->LanguageSettings->Languages
For the specific problem mentioned in this bug (in de-DE locale #-#-# was interpreted as Y-M-D instead of the desired D-M-Y) the patterns could be augmented from D.M.Y;D.M. to
If 3-4 shall not result in a date, D-M- could be used instead of D-M
Note that to enter an ISO 8601 Y-M-D date with a D-M-Y pattern active one needs to enter a year >31 or with at least 3 digits, e.g. 011
Dear bug reporters,
Eike has suggested this bug to be fixed as a late feature in 3.6 with:
to be sure, there are no regression from this, please test a daily build from:
and see if you see any trouble with the fix.