Description: If you create a form with the wizard and default options dates in the table greater than 31/12/2200 are shown incorrectly Steps to Reproduce: 1. Create a table with at least one DATE field 2. Fill table with some data. In the DATE field fill some values greater than 31/12/2200, e.g. 9/9/9999 3. Create a form with the wizard to edit such table, may be with a table format to see all data together, but don´t mind if it is selected another format. Do not modify any control, use the default options to every one. 4. Save the form 5. Open the form to browse data Actual Results: The dates greater than 31/12/2200 are shown as 31/12/2200 regardless of the data in the table Expected Results: Every date shown should be exactly the same than in the table Reproducible: Always User Profile Reset: No Additional Info: This effect is produced by the "Date max" option in the date field control, which is set to 31/12/2200. This control option shouldn't allow introduce (new) dates over the configured date, but it is not expected that the control shows a different date than stored in table
Created attachment 181986 [details] Test database Test database with a table with dates ans forms to see the error
Component changed to UI because it seems a control problem, not a Base problem
I have sent a patch set https://gerrit.libreoffice.org/c/core/+/138845 to discuss. Changes in the patch, solve the problem of view data in a date field control in most databases, which usually their date range goes from 1/1/0001 to 31/12/9999, but still maintains limits on the range of dates that can be viewed. A solution that removes all limits would be better, but I am not able to implement it without help. In any case, the patch extends the range of supported dates to dates before 1/1/1600, which in my opinion is too limiting date, and on the other side it extends the range so that it allows to enter the "magic" date 9/9/9999 which is widely used by database users as the "end of the world" date (the forever date in ranges from-to). This patch could solve too tdf#150587 extending the limits of "Date min" and "Date max" to more reasonable limits
Same behaviour in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Sama konduto en LibreOffice 3.3.0 OOO330m19 (Konstruo:6) etikedo libreoffice-3.3.0.4
also confirmed with: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
jucasaca committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b20594f2fc8f6f9fdbf0b257b4e74d95a8d90139 tdf#150569 Modify hardcoded dates to extend the range of accepted dates It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Be aware that the 1600-01-01 date probably was chosen because it is after the Gregorian calendar 1582-10-15 cut-off date. Dates before that depend on how they are calculated. While the tools Date class operates with a proleptic Gregorian calendar, displaying dates using the number formatter depends on the locale and the Gregorian calendar switch date may also be locale dependent. Earlier dates are usually displayed using the Julian calendar, so what the user sees may not be what the database contains and vice versa, what is entered may not be what is stored. It depends on if and how that is actually handled and likely the code isn't prepared for that because so far it didn't have to. Please make sure this indeed works as intended, i.e. when wanting to store 0001-01-01 or dates between 1582-10-04 and 1582-10-15. Best would be if dates are stored using the proleptic Gregorian calendar as in the ODF file format, everything else would be an uncertain mess. But I don't know if different database formats don't have even different requirements.
(In reply to Eike Rathke from comment #7) > Be aware that the 1600-01-01 date probably was chosen because it is after > the Gregorian calendar 1582-10-15 cut-off date. I was thinking about, and that was why I said maybe needed some discussion. But I saw the lower limits sometimes 1900-01-01, other times 1800-01-01 and other times 1600-01-01 that makes me think that these dates are totally arbitrary. > Dates before that depend on > how they are calculated. While the tools Date class operates with a > proleptic Gregorian calendar, displaying dates using the number formatter > depends on the locale and the Gregorian calendar switch date may also be > locale dependent. Earlier dates are usually displayed using the Julian > calendar, so what the user sees may not be what the database contains and > vice versa, what is entered may not be what is stored. It depends on if and > how that is actually handled and likely the code isn't prepared for that > because so far it didn't have to. When I say that America was discovered on October 12, 1472 by Christopher Columbus, I don't care if the calendar is Gregorian or Julian, I really don't know. But if I write that date in the database, what I hope is that it is stored and maintained as written and when I look for that data again, it has not become January 1, 1600, without any notice, which is what happened so far. > Please make sure this indeed works as intended, i.e. when wanting to store > 0001-01-01 or dates between 1582-10-04 and 1582-10-15. I tested view of data in a form in it was (is) correct (that was that I asked in this bug), but I haven´t realized that in table view dates are shown incorrectly (?). Now, after further tests, I've realized that entering dates is really a mess, depends on where are you introducing data (table view or forms) dates are *modified* in different ways. > Best would be if > dates are stored using the proleptic Gregorian calendar as in the ODF file > format, everything else would be an uncertain mess. But I don't know if > different database formats don't have even different requirements. May be different databases have different requirements, but, I think, Base (LibreOffice) should be neutral about it, i.e. if I write a date in a form or a table view, that date should be stored as is, without any manipulation. If the database does not support the date, it is the database that should complain. Anyway, given the mess, I'm going to ask to revert the patch until further investigation...
Created attachment 182294 [details] Erroneous data view Show errors in dates in table views. Correct in form view
Juan C. Sanz committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5d40ced9e8b0aa1e4c07aea56ed8c1bdaa89705f Revert "tdf#150569 Modify hardcoded dates to extend the range of accepted dates" It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.