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.
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.