Bug 53498 - CONFIGURATION: Add "D/M/Y" as default date recognition pattern for approprtiate countries where missing
Summary: CONFIGURATION: Add "D/M/Y" as default date recognition pattern for approprtia...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
(earliest affected) release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Blocks: 52240
  Show dependency treegraph
Reported: 2012-08-14 16:53 UTC by oconcepcion
Modified: 2012-12-08 17:00 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Screenshot (13.06 KB, image/png)
2012-08-14 16:53 UTC, oconcepcion

Note You need to log in before you can comment on or make changes to this bug.
Description oconcepcion 2012-08-14 16:53:21 UTC
Created attachment 65557 [details]

Problem description: 

Steps to reproduce:
1. Entering ("number"/ or "number"/"number" or "number"/"number"/) + Tab
2. ....
3. ....

Current behavior:
Shows text as entered (for example 14/ or 14/8 or 14/8/)
Expected behavior:
Should recognize date format and show 14/08/12
Platform (if different from the browser): 
Browser: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Comment 1 Lehmeier 2012-08-17 09:27:53 UTC
This bug is very annoying because you can no longer rely solely on the number pad but must always reach over to the keyboard.

Moreover, it is very annoying is that the date processed as text.
Who does not know (ie normal users) assumes that its date is displayed so recently as he entered it but continue to be processed as a date. This produces errors because date and text to be processed differently.

Date as entries 14/08/2012 and14-08-2012, continues to be converted and processed in 14/08/2012 as a date.

This new feature is not perceived as a feature but a bug.

Software should always adapt to the people and not the needs of the software.

On german:

Dieser Bug ist sehr nervend da man nicht mehr nur mit dem Nummernblock arbeiten kann sondern immer auf die Tastatur umgreifen muß.

Ausserdem ist es sehr lästig das daß Datum als Text verarbeitet wird. 
Wer es nicht weiß ( also reine Anwender ) geht davon aus das sein Datum neuerdings so angezeigt wird wie er es eingegeben hat aber weiterhin als Datum verarbeitet wird. Dies produziert Fehler weil Datum und Text unterschiedlich verarbeitet werden. 

Datumseingaben wie 14/08/2012 und14-08-2012 sollten weiterhin in 14.08.2012 umgewandelt und als Datum verarbeitet werden.

Diese neue Funktion wird nicht als Feature wahrgenommen sondern als Bug. 

Software sollte sich immer dem Menschen anpassen und nicht der Mensch der Software.
Comment 2 Rainer Bielefeld Retired 2012-09-24 15:01:07 UTC
This problem should be fixed with fixes for "Bug 52240 - [Task] EDITING: Incomplete Date values are no longer detected"

I mark this one INVALID because too much info is missing.

Please feel free to reopen this Bug if you still see that problem with LibO 3.6.2, but then please contribute complete useful info due to http://wiki.documentfoundation.org/BugReport> (Localization, sample document, ...).

And all relevant Bug wrangler here speak English, no need for German translations except somebody asked your for that.
And a very good way to bore us here are comments like "Software sollte sich immer dem Menschen anpassen ...".
Comment 3 Lehmeier 2012-12-07 16:03:28 UTC
Since the LO 3.6 works with the date 07/12/2012 is no longer in LO Calc.
  But if I> under the "Tools" => "Options" = "Language Settings" => "date pattern recognition" ";D/M/Y" with SPECIFIED then it works again. So I would like this is included by default.

Best regards R.Lehmeier

In German:

Seit der LO 3.6 funktioniert die Datumsangabe mit 07/12/2012 nicht mehr im LO Calc.
 Wenn ich aber unter unter "Extras" => "Optionen" =>"Spracheinstellungen" => "Datumserkennungsmuster" ";D/M/Y" mit angebe dann klappt es wieder. Daher möchte ich das dieses standardmäßig eingefügt wird.

MfG R.Lehmeier
Comment 4 Rainer Bielefeld Retired 2012-12-07 16:43:49 UTC
Please do not translate to German language - we would have asked if that would be useful. You only spam Bugzilla with completely useless text. I already told you.

We need to know for what Locale setting(s) (in the same dialog like the Date recognition pattern) you want to see this by default. I believe it's easy to understand that users in a country with "M/D/Y" (<http://de.wikipedia.org/wiki/Datumsformat>) would not be very happy with "D/M/Y" by default.
Comment 5 Lehmeier 2012-12-08 16:55:29 UTC
Sorry, I just wanted to help you understand the text better, as I translate it with Google. My English is in fact not the best.

Now to the topic:
To LO 3.5.4 (latest 3.5 version used by me before I changed to 3.6.4) there were no problems. It was not until the LO 3.6.
It was very useful if you could use the "/" because they needed to work only on the numeric keypad - an embrace was not necessary.
The new procedure is so unnecessarily complicated, especially since the text is automatically converted from 08/12/2012 to 12/08/2012 and so saved. What would therefore be no problem with an export.
So what is the problem?

Want to liberate their LO of ballast, I can understand, but features that are appreciated by users, but no ballast features.

Before I forget, I use LO in German

Best regards R.Lehmeier

P.S: The default entry is D.M.Y; D.M. A change in DMY, DM, D / M / Y, D / M would therefore not only offers a comfortable complement Amendments of the representation format.
Comment 6 Rainer Bielefeld Retired 2012-12-08 17:00:54 UTC
Currently no Locale known where D/M/Y is missing, so WFM

Please feel free ot reopen if answer to Comment 4 Part 2 shows that we really have a locale where the requested DRC is missing as default