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.
Confirming also on Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 on OSX 10.10.1
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.