Bug 54336 - EDITING: Input in a timestamp-field only with completed date-input possible
Summary: EDITING: Input in a timestamp-field only with completed date-input possible
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:4.0.0.1 target:4.1.0 target:3.6.5
Keywords: regression
Depends on: 52240
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-31 17:48 UTC by robert
Modified: 2013-03-02 08:56 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Database to try the short input with LO 3.5 or earlier and LO 3.6 in a table (3.42 KB, application/vnd.sun.xml.base)
2012-08-31 17:48 UTC, robert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robert 2012-08-31 17:48:15 UTC
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.
Comment 1 Jochen 2012-08-31 18:02:47 UTC
I can confirm the bug.
Changed status to "NEW"
Comment 2 Rainer Bielefeld Retired 2012-08-31 19:11:14 UTC
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.
Comment 3 Rainer Bielefeld Retired 2012-08-31 20:49:57 UTC
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?
Comment 4 Jochen 2012-08-31 21:09:49 UTC
(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.
Comment 5 Eike Rathke 2012-08-31 22:02:38 UTC
(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.
Comment 6 Rainer Bielefeld Retired 2012-09-01 06:00:07 UTC
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
Comment 7 robert 2012-09-01 07:41:13 UTC
@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.
Comment 8 Eike Rathke 2012-12-19 12:38:56 UTC
Taking this.
Comment 9 Not Assigned 2012-12-19 18:41:58 UTC
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.
Comment 10 Not Assigned 2012-12-19 18:42:16 UTC
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.
Comment 11 Eike Rathke 2012-12-19 19:06:03 UTC
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.
Comment 12 Not Assigned 2012-12-21 09:15:05 UTC
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.
Comment 13 Timon 2013-02-28 10:28:04 UTC
In LibreOffice 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) problem is still present.
Comment 14 Eike Rathke 2013-03-01 12:31:03 UTC
(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?
Comment 15 Timon 2013-03-01 16:27:49 UTC
(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.
Comment 16 Eike Rathke 2013-03-01 17:09:18 UTC
(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
Comment 17 Rainer Bielefeld Retired 2013-03-01 17:50:28 UTC
@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".
Comment 18 Timon 2013-03-02 08:56:18 UTC
(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.