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
Would be better if you could attach a little database. I don't know what you mean with "time text box".
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.
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
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.
One hint: If you would chose a formatted field it should work for you - but didn't solve the bug.
I have switched the version to 4.1.0.0.beta1 - the first version I could test where the bug appears.
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.
Created attachment 83031 [details] Time field not displaying existing (nonzero) table values anymore
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.
(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
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
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.
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
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
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
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.
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
Fix is at https://gerrit.libreoffice.org/5149, but raises issues, so to be discussed.
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.
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.
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.
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.
*** Bug 68094 has been marked as a duplicate of this bug. ***