Created attachment 66413 [details] Database to try the short input with LO 3.5 or earlier and LO 3.6 in a table Up to LO 3.5.* you could create timestamp-fields in tables (and also in forms), where you have to input only day and month and the time. The GUI completed the year automatically. Example (German) "28.8 13:30" → "28.08.12 13:00" Since LO 3.6.* the date isn't completed. When you try the same you get: "28.8 13:00" → "30.12.99 00:00" LO 3.6 could not read the old, short input.
I can confirm the bug. Changed status to "NEW"
This one might be more or less a DUP of "Bug 52240 - [Task] EDITING: Incomplete Date values are no longer detected". In a first quick test unzipped MinGW Master "3.7.0.0.alpha+ [Build ID: 4deb9d4] English Locale/UI {Win-x86@7-MinGW pull time 2012-08-31 05:20:19} on WIN7 Home Premium (64bit) was not able to handle that. @Robert: can you please check with current Master whether that new date input pattern heals your problem? Date-time input might be something what has to be considered additionally.
Jochen, please no harmful excessive zeal, I told you for what NEEDINFO Status is! <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_Status_or_Keyword_NEEDINFO>. Here vailable info is absolutely sufficient, bug fixing process is already ongoing, so NEEDINFO here it would be completely wrong. May be the linked description is misinterpretative and/or incomplete and should be improved?
(In reply to comment #3) > Jochen, please no harmful excessive zeal, I told you for what NEEDINFO Status > is! > <https://wiki.documentfoundation.org/QA-FAQ#How_to_use_Status_or_Keyword_NEEDINFO>. > Here vailable info is absolutely sufficient, bug fixing process is already > ongoing, so NEEDINFO here it would be completely wrong. May be the linked > description is misinterpretative and/or incomplete and should be improved? @Rainer: I don´t understand what you mean. I changed status from "UNCONFIRMED" to "NEW". Why do you mention "NEEDINFO"? May be I have mistyped. In that case sorry.
(In reply to comment #0) > Example (German) > "28.8 13:30" → "28.08.12 13:00" > Since LO 3.6.* the date isn't completed. When you try the same you get: > "28.8 13:00" → "30.12.99 00:00" 28.8. 13:00 should work though, note the trailing dot in date. If yes, then this is a duplicate of bug 52240.
Th longer I think about that the more Isee 2 eparate parts within this bug: As reporter said 3.5.6.2 recognized "28.8 13:30" → "28.08.12 13:00" That is the input of an invalid unusual date, in future our "Date acceptance Patterns" enhancement should be enhanced to a "Date/Time acceptance Patterns" feature to handle such desires "28.8. 13:30" → "28.08.12 13:00" I think "28.8. 13:30" is a usual valid input for "German" locale setting and should be recognized without any additional settings
@Rainer, this isn't a duplicate of Bug 52240. There are two differences: The input is given with a dot between the day and month - works in Base and Calc before 3.6.* . In 3.6.* you have to put a dot behind the value for the month. The main problem is the timestamp-field in a database-table. In former versions I could write 3.4 15:00 → 3.4.12 15:00 This won't work any more. Same problem with the dot behind the month-value: 3.4. 15:00 → 30.12.99 00:00 in LO since 3.6 - also the new LODev. Have a look at the typical German input for a date: Day.Month. At least the year should be added automatically, when there are two dots. There is also a difference between Clac-fields and Base-fields: Fiels in a database are formatted with a field-type. You could only put a date in a date-field, a time in a timefield. So it musn't be a problem for a program to change day.month without a dot after the month-value to a complete date. Isn't a problem for me - I have just reported a difference a Base-user asked about in the german libre-office-forum. My favorit input is a date with two dots and without a year, when the current year should be added. This works in Base with date-fields also in 3.6.*, but not with timestamp-fields. I don't konwo where to get a rpm-Master of 3.7 to test this there. But you could test the behaviour with the added table in the database.
Taking this.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0e8b3410fb26a2b463ad47387bc9aede7ee05fb3&g=libreoffice-4-0 resolved fdo#54336 accept abbreviated combined date/time input It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2851a270eb9c617fce9bfdde5c8f2428ced7014 resolved fdo#54336 accept abbreviated combined date/time input The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Change pending for review for 3-6 as https://gerrit.libreoffice.org/1423 Note that the abbreviated date input must match one of those defined under Tools->Options->LanguageSettings->Languages Date acceptance patterns, i.e. for de-DE German default D.M. including trailing dot if nothing else defined.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd7a679774088cfbbadcca9434b10f0089fd2a49&g=libreoffice-3-6 resolved fdo#54336 accept abbreviated combined date/time input It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
In LibreOffice 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) problem is still present.
(In reply to comment #13) > In LibreOffice 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) > problem is still present. In what locale for what input in what application?
(In reply to comment #14) > (In reply to comment #13) > > In LibreOffice 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) > > problem is still present. > > In what locale for what input in what application? In Calc in Russian locale. If we format cell as Date (even as dd.mm.yy hh:mm) after input "28.8 13:30" nothing happens.
(In reply to comment #15) > In Calc in Russian locale. If we format cell as Date (even as dd.mm.yy > hh:mm) after input "28.8 13:30" nothing happens. The predefined ru-RU date acceptance patterns are D.M.Y;D.M.;D/M/ so the input should be 28.8. 13:30 note the trailing dot after month. You can check and edit the date acceptance patterns under Tools->Options->LanguageSettings->Languages
@Timon If there still is a real problem, please open a separate Bug with a complete bug description doe to <http://wiki.documentfoundation.org/BugReport> and add me to CC! It's not useful to start a longer discussion in a fixed bug with only "the bug still exists".
(In reply to comment #17) > @Timon > If there still is a real problem, please open a separate Bug with a complete > bug description doe to <http://wiki.documentfoundation.org/BugReport> and > add me to CC! It's not useful to start a longer discussion in a fixed bug > with only "the bug still exists". Thanks. After Eike Rathke explanations problem is solved.