Bug 67235 - EDITING: Timefield is limited automatically to max. 00:00:01
Summary: EDITING: Timefield is limited automatically to max. 00:00:01
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.1.0.0.beta1
Hardware: All All
: highest blocker
Assignee: Lionel Elie Mamane
URL:
Whiteboard: BSA target:4.2.0 target:4.1.1
Keywords: regression
: 68094 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-07-24 03:00 UTC by danin7777
Modified: 2014-07-21 08:23 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
The information fields in both tables help explain the problem I'm having. (12.07 KB, application/vnd.oasis.opendocument.database)
2013-07-25 02:49 UTC, danin7777
Details
Timefield in a tablecontrol is limited to 1 second (9.55 KB, application/vnd.sun.xml.base)
2013-07-25 07:03 UTC, Robert Großkopf
Details
Time field not displaying existing (nonzero) table values anymore (145.95 KB, image/jpeg)
2013-07-26 12:01 UTC, Luzius Auer
Details
Timefield in a tablecontrol is limited to 1 second, in a normal control to 0 second (17.23 KB, application/vnd.sun.xml.base)
2013-07-27 07:21 UTC, Robert Großkopf
Details
com.sun.star.util.Time has been changed in LO 4.1.0 - could this give a hint? (33.05 KB, image/png)
2013-07-27 07:29 UTC, Robert Großkopf
Details
Timefield and time in a formatted field for a timestamp are broken (18.26 KB, application/vnd.sun.xml.base)
2013-07-27 07:57 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description danin7777 2013-07-24 03:00:55 UTC
Problem description: When you create a main form with a subform with a time text box in the subform, the "time max" setting always reverts to 00:00:01 when you save the form, so you cannot read or change any times. I have not tested this in Windows since I can't take a chance on losing this function.

Steps to reproduce:
1. Create new database
2. Create 2 tables including 1 field in each to connect main form with subform, and including a time text box in the subform
3. Use wizard to create main form and subform including the time text box

Current behavior:
You will be unable to see or change any times in the time text box. "Time max" setting for the text box remains at 00:00:01 when you try to change it and save the form. This happened in both data sheet view and with text boxes.

Expected behavior:
Times will show correctly in the time text box in the subform, you will be able to change times in the text box, and changes to the "time max" setting will be saved

              
Operating System: Debian
Version: 4.1.0.1 rc
Comment 1 Robert Großkopf 2013-07-24 18:22:12 UTC
Would be better if you could attach a little database. I don't know what you mean with "time text box".
Comment 2 danin7777 2013-07-25 02:49:24 UTC
Created attachment 82973 [details]
The information fields in both tables help explain the problem I'm having.

Open the form and try to change the time. Then try to adjust the control settings to make the time box & column (both main & subform in this case) work.
Comment 3 danin7777 2013-07-25 02:51:14 UTC
I don't know where the bug started, but I had to pick a version. I know it didn't happen in 4.0.3. I never tested it in any version other than Debian. I use Ubuntu 12.04 for my OS, with latest updates. I had to quit using 4.0 because reports stopped working in 4.0.4
Comment 4 Robert Großkopf 2013-07-25 07:03:06 UTC
Created attachment 82979 [details]
Timefield in a tablecontrol is limited to 1 second

I can confirm this bug. It isn't a problem of the subform. So I created a new form and a tablecontrol with a timefield. All timefields in a tablecontrol are automatically limited to 00:00:01. You could see this, when you try to change the value of one row and then have a look to the table, 00:00:01 appears.

The timefield in a tablecontrol works right LO 4.0.4.2.
Comment 5 Robert Großkopf 2013-07-25 07:12:08 UTC
One hint:
If you would chose a formatted field it should work for you - but didn't solve the bug.
Comment 6 Robert Großkopf 2013-07-25 07:26:56 UTC
I have switched the version to 4.1.0.0.beta1 - the first version I could test where the bug appears.
Comment 7 danin7777 2013-07-26 01:54:49 UTC
If you're saying the problem only occurs in the datasheet view, please check the "TimeWorksCorrectly" text box in the "MainFormWithSubForm" form in the file I uploaded. The text box with a time field does the same thing as it does in the datasheet view in the subform. I discovered this after making the test database to upload.
Comment 8 Luzius Auer 2013-07-26 12:01:25 UTC
Created attachment 83031 [details]
Time field not displaying existing (nonzero) table values anymore
Comment 9 Luzius Auer 2013-07-26 12:08:37 UTC
Same bug still present in the 4.1.0.4 release.
This is a blocker for us, as we are unable to read/change/assign course beginning times.
Comment 10 Robert Großkopf 2013-07-26 17:49:14 UTC
(In reply to comment #9)
> Same bug still present in the 4.1.0.4 release.
> This is a blocker for us, as we are unable to read/change/assign course
> beginning times.

Please see:
https://bugs.freedesktop.org/show_bug.cgi?id=67235#c5

Please do not change the version to the latest version the bug appears. Everybody, who could fix bugs, would search: What has been changed that this bug appears.
The first version the bug appears I have tested is 4.0.0.0.beta1
Comment 11 Katrina Adams 2013-07-27 00:57:47 UTC
Hello,

I may have another manifestation of the same bug. The LO version is 4.1.0.4 running on Ubuntu 12.04.

We have a database, HSQLDB 2.3, which is used to store employee work time. We use Base as the front end. We use a split configuration db which is stored in a shared Dropbox folder.

Two computers access the DropBox files, one is running Windows 8/LO 4.0.3.3 and the other is running Ubuntu 12.04/LO 4.1.04.

All the tables, etc have been developed on the Windows machine.

One table has 3 timestamp fields, two are set to default to current_timestamp when the record is created and the 3rd field is set to current_timestamp after a triggering event occurs.

When you open the table in the Ubuntu LO the displayed dates are correct, however all times are set to 12:00 am. Although the display is incorrect, the correct system time is being recorded in the database. This is verified when the table is opened in the Windows LO, where all the records are correctly displayed.

All formats in the table, forms and reports are set correctly.

As a test I copied data from the table as displayed on the Ubuntu machine and pasted it into a Calc spreadsheet. The times were incorrectly displayed.

I repeated the test on the Windows machine (accessing the same database), pasted the records into a spreadsheet, saved the spreadsheet and opened it on the Ubuntu machine. This time the time display was correct.

I have also created a new table with a field default set to current_timestamp using the Ubuntu LO. This new table records the correct time in the db, but displays the incorrect time. 

I tried a query using datediff and the hours were calculated correctly, so the problem seems limited to the display.

If this is posted in the wrong place, please let me know so I can repost correctly.

Cheers,
Katrina
Comment 12 Robert Großkopf 2013-07-27 07:21:42 UTC
Created attachment 83077 [details]
Timefield in a tablecontrol is limited to 1 second, in a normal control to 0 second

The bug doesn't appear only in a tablecontrol. It could be also found in a normal timefield.
All values of a timefield in a tablecontrol were shown as "00:00" when chosen hours:minutes.
Values in a normal timefield don't show any value when you open the form.
Comment 13 Robert Großkopf 2013-07-27 07:29:10 UTC
Created attachment 83078 [details]
com.sun.star.util.Time has been changed in LO 4.1.0 - could this give a hint?

Tests with Windows give the same result. Timefield is broken in LO 4.1.0.4. Attachment is one hint from the german libreoffice-forum: http://www.libreoffice-forum.de/viewtopic.php?f=10&t=12248&start=10#p22635
Comment 14 Robert Großkopf 2013-07-27 07:57:06 UTC
Created attachment 83080 [details]
Timefield and time in a formatted field for a timestamp are broken

Have read
https://bugs.freedesktop.org/show_bug.cgi?id=67235#c11
And the had a look at the timestamp. Its the same behavior in a formatted field with a timestamp - Time is shown as 00:00
Comment 15 Robert Großkopf 2013-07-27 08:01:52 UTC
Hello Lionel,
The input of time through a form is broken. Could you please have a look? or do you know someone else, who is working on form-controls in Base?

Many thanks for all what you are doing for Base.

Regards

Robert
Comment 16 Robert Großkopf 2013-07-27 08:07:15 UTC
I will open a new bug. The time in the formatted field is broken in 4.1, not in 4.0
https://bugs.freedesktop.org/show_bug.cgi?id=67235#c11
https://bugs.freedesktop.org/show_bug.cgi?id=67235#c13
https://bugs.freedesktop.org/show_bug.cgi?id=67235#c14
are obsolete for this bug-report.
Comment 17 Robert Großkopf 2013-07-28 08:01:40 UTC
Seems to be I am a little bit confused by testing all this versions. With LO 4.0.4.2 all the fields work right - see https://bugs.freedesktop.org/show_bug.cgi?id=67235#c4

The timefield is first broken in LO 4.1.0.0.beta1. Version in https://bugs.freedesktop.org/show_bug.cgi?id=67235#c10 is wrong.

The time in a formatted field (timestamp) is first broken in LO 4.1.0.2. This is right in https://bugs.freedesktop.org/show_bug.cgi?id=67387
Comment 18 Lionel Elie Mamane 2013-07-28 15:25:25 UTC
Fix is at https://gerrit.libreoffice.org/5149, but raises issues, so to be discussed.
Comment 19 Commit Notification 2013-08-02 11:41:06 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed904af8665f6f7590fedd4ad608018f78c686c1

fdo#67235 adapt form control code to time nanosecond API change



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 20 Commit Notification 2013-08-03 09:24:48 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f4cadd9772ed0ff6e7f7b170080f90384d1f2318

fdo#67235 adapt form control code to time nanosecond API change, step 2



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 21 Commit Notification 2013-08-04 06:58:27 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ee69b0ba13f74d1515fac71df92947eb6328ab1

fdo#67235 adapt form control code to time nanosecond API change, step 3



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 22 Commit Notification 2013-08-04 09:14:25 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=43ea97e1f9cecd6c7cba8db35ce1307c858c6857&h=libreoffice-4-1

fdo#67235 adapt form control code to time nanosecond API change


It will be available in LibreOffice 4.1.1.

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 23 Jean-Baptiste Faure 2014-07-20 12:48:55 UTC
*** Bug 68094 has been marked as a duplicate of this bug. ***
Comment 24 Jean-Baptiste Faure 2014-07-21 08:23:32 UTC
*** Bug 68094 has been marked as a duplicate of this bug. ***