Created attachment 65557 [details] Screenshot 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
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.
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. @Reporter 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, ...). @Lehmeier 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 ...".
Hello! 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: Hallo! 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
@Lehmeier 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.
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.
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