Bug 52137

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.