I opened Base table in Edit mode and entered a date format e.g. mm/dd/yy and a default value in the same format e.g. 07/01/16. Closing the edit mode and opening the table, there was a wrong value for the date. Someone on the LibreOffice forum suggested leaving the format entry as is, but entering the default value using format yyyy-mm-dd. This worked, except that (1) opening the table, the default value shown was two days later than what I had entered in the Edit mode; (2) re-opening the Edit mode, each time I clicked on that date field, two additional days had been added to the default value. I finally entered a default date in yyyy-mm-dd format but two days earlier than what I wanted, and refrained from checking back on that field.
@stroy : 1) what is your locale/language setting ? 2) please provide a sample ODB file where the problem appears and explain how to reproduce the issue. Setting to NEEDINFO, please set back to UNCONFIRMED once you have done this.
Seems similar to the behaviour described in bug 96190, but without a test ODB file I'm just guessing.
Created attachment 127849 [details] DateFormatDemo.odb
(In reply to Alex Thurgood from comment #1) > @stroy : > > 1) what is your locale/language setting ? > > 2) please provide a sample ODB file where the problem appears and explain > how to reproduce the issue. > > Setting to NEEDINFO, please set back to UNCONFIRMED once you have done this. 1) My locale/language setting is Default-English (USA) 2) I am attaching a demo file.
@stroy : when I open your file and then the table in Edit mode, I see that the date field StartDate has been formatted as 01/01/00 and if I click on the ellipsis button next to that formatting window, I get the usual LO number formatter dialog. This dialog indicates that the field is configured as a number and not a date (Category > Number, Format > Standard). I left the default and then closed table edit mode and opened the Table view/data entry mode where I can see the data already in the table. The first and only line of data gives a displayed date value of 06/10/16. What date value did you actually enter ? I entered 07/01/20 as the date in a new entry, and some random text string. The date displayed as 07/01/20, even after closing and re-opening the table. If I click on the field header of the open table, and choose Column Format, I get a dialog that indicates that the field is configured as a Date, and in the DD/MM/YY format. If I change the language to English(USA), I get the default date format of MM/DD/YY. This setting works for me and survives a shutdown and reload of the ODB file. Tested against Version: 5.3.0.0.alpha0+ Build ID: 44170554cc9c0411c2ed6720fd09bedee2a9a162 Threads CPU : 2; Version de l'OS :Mac OS X 10.12; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group I don't see a two day difference in date values. What setting have you put in Calc for the default date under LibreOffice > Preferences > Calc > Calculations > Date ? Which time zone are you operating in ? The Java date function, which is what is used in hsqldb (the default embedded database engine in ) to manage dates, is known to be dependent on timezone corrections, which can lead to date display offsets in LO Base (and thus incorrect display).
Created attachment 127863 [details] Default-value of a date adds 2 days each time you leave the row of the date There is a description with screenshots in the attachment. Add a default-value while editing the table. Change to another row and go back. 2 days have been added. Save the table. Again tow days have been added. Every time you move from the row, which contains the date, to other rows and back there will be added 2 days. I could confirm this buggy behavior for OpenSUSE 42.1 64bit rpm Linux and LO 5.2.2.2.
Seems to be a very old bug: I could also confirm it with LO 3.6.7.2. Could be this bug is inherited from OOo. Could also confirm with version: 5.3.0.0.alpha0+, Time: 2016-08-23_13:10:42
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
*** Bug 122140 has been marked as a duplicate of this bug. ***
(In reply to Robert Großkopf from comment #9) > *** Bug 122140 has been marked as a duplicate of this bug. *** on the duplicate issue it is clear that it is not just a two day change, the year part of the date is messed up also with the Firebird backend. I could add the FB example to this issue so that distinction isn't lost in the fix?
(In reply to Drew Jensen from comment #10) > (In reply to Robert Großkopf from comment #9) > > *** Bug 122140 has been marked as a duplicate of this bug. *** > > on the duplicate issue it is clear that it is not just a two day change, the > year part of the date is messed up also with the Firebird backend. > > I could add the FB example to this issue so that distinction isn't lost in > the fix? Are you shure the year will also be changed? I have tested it with a Firebird and a HSQLDB on LO 6.1.4.2 with OpenSUSE 15, 64bit rpm Linux. Couldn't find any difference between the behaviour of both internal databases.
(In reply to Robert Großkopf from comment #7) > Seems to be a very old bug: I could also confirm it with LO 3.6.7.2. I believe the change happened from commit fb162871bea92577e72437e59e1dfc1d2e6b3a93 by Author: Ocke Janssen <oj@openoffice.org> on Date: Thu Sep 26 09:49:09 2002 +0000 #102963# SetEvalDateFormat(NF_EVALDATEFORMAT_FORMAT) to use the format key at the number formatter specifically with the single use of toNullDate() in nValue = DBTypeConversion::toNullDate(DBTypeConversion::getNULLDate(xNumberFormatter->getNumberFormatsSupplier()),nValue);
I can still reproduce this in: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6e66b5d75b4cda0314b64f4d12ef9e4350751470 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 152021 has been marked as a duplicate of this bug. ***
repro 7.6+ Note: it is in design (editing the table's settings) where this is seen, not in data entry.