Created attachment 64259 [details] example for date the local date format (german) converts the date to the american format only in 3.6.0.1 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 <http://en.wikipedia.org/wiki/Date_and_time_notation_by_country> <http://en.wikipedia.org/wiki/Date_and_time_notation_in_the_United_Kingdom> <http://en.wikipedia.org/wiki/Date_and_time_notation_in_the_United_States> @gerdl: Please: – 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 3.6.0.1 with German dialogs same with the actual nightly build with English dialogs. how to: start libreoffice create a new empty calc sheet write 16-07-12 into one of the cells, date of today in german notation type enter the cell now contains: 2012-07-16 i would expect 16-07-2012 german date format. but write 27-07-12 date at end of this month in german notation type enter 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 ge
@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 just tested with version 3.6.0.2 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
@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. > but > 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...
http://cgit.freedesktop.org/libreoffice/core/commit/?id=cda156257003df673fa853a0a5ffcd1cb4848d43 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 D.M.Y;D.M.;D-M-Y;D-M 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: https://gerrit.libreoffice.org/#/c/511/ to be sure, there are no regression from this, please test a daily build from: http://dev-builds.libreoffice.org/daily/ and see if you see any trouble with the fix.