Bug 108471 - In a Form Table Control the Default time is not working in Date/Time (time) fields.
Summary: In a Form Table Control the Default time is not working in Date/Time (time) f...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2017-06-12 01:33 UTC by Howard Johnson
Modified: 2023-01-24 10:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample database file (12.71 KB, application/vnd.sun.xml.base)
2017-06-12 01:33 UTC, Howard Johnson
Details
Firebird error message (13.60 KB, image/png)
2017-06-13 18:07 UTC, Howard Johnson
Details
Sample database using firebird (10.34 KB, application/vnd.sun.xml.base)
2017-06-13 18:10 UTC, Howard Johnson
Details
DateTime default working in formatted field, if defined in table (12.62 KB, application/vnd.oasis.opendocument.database)
2023-01-20 15:09 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Howard Johnson 2017-06-12 01:33:00 UTC
Created attachment 133959 [details]
Sample database file

The Summary/title line above says it all.

To demonstrate this feature open the form in the attachment.  Click on the 4th line in either table control to start a new record. Note that defaults are working for all but the Date/time (Time) field which gets 0:00 rather than the set default.

Contrast this with the fact that defaults do work properly for Time, Date, and Date/Time (Date) type fields.  In addition all of these work properly in Tables and Queries.  It's only Form, Table control, Date/Time (time) fields that don't work properly.

I have tested this both with the embedded HSQLDB 1.8 and with a connected MariaDB 10.1.  The attachment here only uses the embedded HSQLDB database.

Associated issues: I think there are also other related issues with the inability to easily enter dates and times in Table Controls, and will submit as separate issues.  But I note this here because at the same time as someone is working on this they might also want to fix some other related issues.

Note that if you create a table control using the wizard, using an underlying data source with a Date/Time type field, the wizard will create two Table Control columns: a Date/time (Date) and a Date/time (Time).  It's the 2nd of these that is not working properly.

Debian Jessie 8.8-64 w/ cinnamon 2.2.16.

Thanks.
Comment 1 Buovjaga 2017-06-12 11:01:03 UTC
Reproduced with file.

Did you also test with Firebird?

Win 7 Pro 64-bit Version: 5.4.0.0.alpha1+ (x64)
Build ID: d02d52887678cd3d518c19a235bc443c292b3041
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2017-05-01_22:53:14
Locale: fi-FI (fi_FI); Calc: CL
Comment 2 Howard Johnson 2017-06-13 18:07:27 UTC
Created attachment 134000 [details]
Firebird error message
Comment 3 Howard Johnson 2017-06-13 18:08:20 UTC
(In reply to Buovjaga from comment #1)
> Reproduced with file.
> 
> Did you also test with Firebird?

I just tested w/ Firebird.  Yes this also happens w/ Firebird, but w/ different error message:

"Error updating the current record

firebird_sdbc error:
*value exceeds the range for valid timestamps
caused by
'isc dsql execute'"
Comment 4 Howard Johnson 2017-06-13 18:10:36 UTC
Created attachment 134001 [details]
Sample database using firebird
Comment 5 Julien Nabet 2018-01-25 09:55:37 UTC
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.

Just for my information, where do you put default time, date or other?
In table design, default values are empty and I don't find other places.
Comment 6 Alex Thurgood 2019-01-07 15:06:05 UTC
Thought this was a regression, but having tested against 

Version: 4.4.5.2
Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Locale : fr_FR.UTF-8
macOS 10.14.2

it seems like this was the beahviour at least back to that version.

Testing earlier versions of LO is complicated on macOS because it requires the presence of the JavaforOSX package which is deprecated.
Comment 7 Alex Thurgood 2019-01-07 15:11:14 UTC
I can also reproduce this in 

Version: 4.2.5.2
Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5
Comment 8 Julien Nabet 2019-01-17 08:01:59 UTC
I gave it a try with master sources updated yesterday.
1) Firebird file shows no table for me even if I enable advanced features and no message on console to indicate why.
2) I could reproduce this with hsqldb but and had different messages on console:
warn:tools.datetime:6904:6904:tools/source/datetime/tdate.cxx:102: Date::setDateFromDMY - sure about 0 year? It's not in the calendar
warn:legacy.osl:6072:6072:svx/source/fmcomp/gridctrl.cxx:2120: DbGridControl::SetCurrent : SeekRow failed !
warn:legacy.osl:6072:6072:svtools/source/brwbox/brwbox3.cxx:376: Illegal call here!
Between datetime format in table, datetime format in forms, the different date limits between database types, I'm lost
=> I can't help here, uncc myself
Comment 9 QA Administrators 2021-01-17 04:11:43 UTC Comment hidden (obsolete)
Comment 10 Howard Johnson 2021-01-17 04:30:20 UTC
I think these 'Dear xx' letters are stupid and I refuse to put more time into this until there is a real effort to fix these bugs.  It would be ok to just let them hang, but these letters asking us to reconfirm again and again just rub me the wrong way.
Comment 11 Buovjaga 2021-01-17 08:08:23 UTC
(In reply to Howard Johnson from comment #10)
> I think these 'Dear xx' letters are stupid and I refuse to put more time
> into this until there is a real effort to fix these bugs.  It would be ok to
> just let them hang, but these letters asking us to reconfirm again and again
> just rub me the wrong way.

I get where you're coming from, but numerous experiments have shown that retesting after 1 year yields about 25% "silently fixed" reports (ie. might have been duplicates). It is true that for some areas that are not seeing intensive work, such as Base, it is a bit problematic to keep pinging.
Comment 12 Alex Thurgood 2021-01-19 12:13:48 UTC
(In reply to Buovjaga from comment #11)


> 
> I get where you're coming from, but numerous experiments have shown that
> retesting after 1 year yields about 25% "silently fixed" reports (ie. might
> have been duplicates). It is true that for some areas that are not seeing
> intensive work, such as Base, it is a bit problematic to keep pinging.

It is indeed very rare for anything Base related to get fixed by "accident", or as a result of a fix somewhere else in the code.
Comment 13 Alex Thurgood 2021-01-19 12:17:11 UTC
(In reply to Howard Johnson from comment #10)
> I think these 'Dear xx' letters are stupid and I refuse to put more time
> into this until there is a real effort to fix these bugs.  It would be ok to
> just let them hang, but these letters asking us to reconfirm again and again
> just rub me the wrong way.


I argued this very point many years ago when the "bug the original bug reporter" email idea was first floated, but then I'm mostly a Base/Writer user, on a 2nd class OS, where LO is concerned ;-)

You can still have my +1 though.
Comment 14 QA Administrators 2023-01-20 03:24:46 UTC Comment hidden (obsolete)
Comment 15 Robert Großkopf 2023-01-20 15:08:41 UTC
Have tested this one. Seems to be a little tricky but got it working. Only time in a form control, which is defined as time from a TIMESTAMP field, won't work.

1. Create the table with data and datetime fields
2. Set the defaults in this table. For a date and a datetime field it will only work with
YYYY-MM-DD
YYYY-MM-DD HH:MM:SS
If I try it with the German format, with is shown as example it didn't work. But it will show the fields formatted in German format …
3. Create a form with a separate date and time field an a formatted field for datetime.

Form will show the default values for datetime in the formatted field. Only wouldn't show the right default time in the separate time field.

Tsted with
Version: 7.5.0.2 (X86_64) / LibreOffice Community
Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58
CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
(OpenSUSE 15.3 64bit rpm Linux)
Comment 16 Robert Großkopf 2023-01-20 15:09:36 UTC
Created attachment 184792 [details]
DateTime default working in formatted field, if defined in table
Comment 17 Robert Großkopf 2023-01-20 15:14:29 UTC
Comment on attachment 134001 [details]
Sample database using firebird

File doesn't contain any database. Seems to contain a form, which isn't shown when opening the file.
Comment 18 Robert Großkopf 2023-01-20 15:24:46 UTC
Bug for the separate Time control for a datetime-field of the database still exists.
Tested with OpenSUSE 15.3 64bit rpm Linux, LibreOffice 7.5.0.2
Comment 19 Alex Thurgood 2023-01-24 10:48:07 UTC
Confirming that bug still present also in

Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 7f23dae00fedc9d7119b44b6c44d9eca4f8c87b8
CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

daily build master 24/01/2023.