Bug 88560 - Wrong Date-input in form gives different values, depended on fieldproperties
Summary: Wrong Date-input in form gives different values, depended on fieldproperties
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2015-01-18 17:30 UTC by Robert Großkopf
Modified: 2023-11-07 09:34 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Open "Form_Date_Datefield", input a wrong date-value like 31.6.14. Do the same in the table. (18.79 KB, application/vnd.oasis.opendocument.base)
2015-01-18 17:30 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2015-01-18 17:30:52 UTC
Created attachment 112427 [details]
Open "Form_Date_Datefield", input a wrong date-value like 31.6.14. Do the same in the table.

Open the attached database. 
The following steps were made with German GUI and Schema:
Open "Form_Date_Datefield".
You will see two fields, no entry is made.
Set ID '1' and Date '31.6.14', which is a wrong date-value.
Go to next row.
Go back.
You will see the date from today instead.

Close the form, open the table directly for inpu data. Type ID '2' and Date '31.6.14'. Date will show '30.12.99', which means '1899-12-30'. Change this value to a normal existing value, for example '16.01.15'.

Reopen the form.
Put in a new date-value:
Set ID '3' and Date '31.6.14', which is a wrong date-value.
Go to next row.
Go back.
You will see the date from row 2 instead of the wrong input.

Wrong date-value in a date-field in a form give the date of now, if there isn't a value in last row. If it finds a value in last row it will use this value.

Now try the other "Form_Date_formatted_Field". This does work exactly as the table itself would work: wrong entry gives '1899-12-30' - which istn't correct, but better than using a value, which seems to be correct. The behavior of the datefield could led to dataloss. So I set the Severity to major.
Comment 1 Alex Thurgood 2015-01-19 14:28:53 UTC
Confirming also on 

Version: 4.3.5.2
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5

on OSX 10.10.1
Comment 2 Alex Thurgood 2015-01-19 14:31:30 UTC
This rings a bell with regard to the use of today's date as default when in a form control, but can't remember whether it is a deliberate change or not. Unofrtunately, this new behaviour is inconsistent with the behaviour of the grid in Table view data entry mode.
Comment 3 Robert Großkopf 2016-03-05 10:48:33 UTC
Bug appears also in the first available LO-version (LO 3.3.0.4, OpenSUSE 42.1 64bit rpm Linux). So I set this bug as "Inherited From OOo".
Comment 4 QA Administrators 2017-10-23 14:14:50 UTC Comment hidden (obsolete)
Comment 5 Robert Großkopf 2017-10-26 07:14:09 UTC
Tested again with Version: 6.0.0.0.alpha0+
Build ID: cfbb8b5090537e79ba70e250ddee86d53facbe15
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-10-18_22:54:20
Locale: de-DE (de_DE.UTF-8); Calc: group
on OpenSUSE 42.2.
Nothing changed in the buggy behavior.
Comment 6 QA Administrators 2018-11-03 03:49:49 UTC Comment hidden (obsolete)
Comment 7 Robert Großkopf 2018-11-05 20:11:23 UTC
Bug still exists in LO 6.1.3.2 64bit rpm Linux. Wrong date in a datefield of a form changes to value of current date. Could be somebody had implemented this to get the current data as default-value to this form-field. Have tested this - will work well! But if there is somebody who will fix this bug I can't use this "trick".
Comment 8 QA Administrators 2019-11-06 03:31:24 UTC Comment hidden (obsolete)
Comment 9 Robert Großkopf 2019-11-06 14:54:30 UTC
Bug still exists with LO 6.3.3.2 on OpenSUSE 64bit rpm Linux.
Comment 10 QA Administrators 2021-11-06 03:54:54 UTC Comment hidden (obsolete)
Comment 11 Robert Großkopf 2021-11-06 07:17:33 UTC
Bug still exists in LO
Version: 7.2.2.2 / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
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
Comment 12 QA Administrators 2023-11-07 03:14:29 UTC Comment hidden (obsolete)
Comment 13 Robert Großkopf 2023-11-07 09:34:32 UTC
Bug still exists in LO 7.6.2.1 on OpenSuSE 15.4 64bit rpm Linux.