Dates entered into chart scale endpoints have month and day values flipped. I'm in U.S. using MM/DD/YYYY format. Entering 05/01/19 changes to 01/05/19 and displays as January 5. Entering 01/05/19 changes to 05/01/19 and displays as May 1. Using date increment buttons results in mixed math: 1/5/19, 5/2/19, 2/6/19, 6/3/19, 3/7/19, ...
Thanks for filing but could you please post a sample calc sheet and sample data with chart that is having issue with date formats so we don't have to guess at your layout. Helps the process.
Created attachment 152051 [details] Calc file Here's a log with a progress chart. Open the chart's Scale dialog for the x-axis. i.e., Double-click the chart and double-click the x-axis. Replace Minimum value with 1/5 and tab out of the field. I see 01/05/2019. Good. Replace Minimum value with 1/5/19 and tab out of the field. I see 05/01/2019. Bad. Poke Minimum value's up arrow. I see 05/02/2019. Good (given its starting point was 5/1). Poke Minimum value's up arrow. I see 02/06/2019. Bad. Etc. If I make a different window active between pokes of the Up arrow, behavior seems OK for one poke before reverting to described behavior. The behavior seems symmetric in that poking the Down arrow can get you back to starting value.
On Windows 10 Home 64-bit en-US with Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Verified user profile set with default Tools -> Options -> Languages Settings -> Language: Date acceptance patterns of 'M/D/Y;M/D' Enabling Chart OLE Selecting and opening the x-axis dialog: on the Scale tab starting date and ending date show 'MM/DD/YYYY', but on the dialog's Numbers tab the Date -> Format Code is set to 'DDMMMYY' --which is the format the Chart shows. With these settings: using the spin buttons to adjust starting date, the actual date assigned is erratic--flipping between MMDDYY and DDMMYY format--and looks like subsequent button spin reparses the date while toggling back. Gets wrong dates as it passes month threshold. But, changing the X-Axis Numbers tab Date -> Format Code to 'YY-MM-DD' using the spin button for the Scale cleanly increments and chart dates are correct passing month boundaries. So some weird juxtaposition of Date acceptance patterns and the Date format used on chart axis?
Same mis handling of date format in current master /6.4.0alpah0 build Version: 6.4.0.0.alpha0+ (x86) Build ID: 9870ff897f088563426bee9567dd9cb722c2b929 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Could anyone explain the specific steps to reproduce this issue? I've spent 10 minutes trying to reproduce it and I couldn't
(In reply to Xisco Faulí from comment #5) > Could anyone explain the specific steps to reproduce this issue? I've spent > 10 minutes trying to reproduce it and I couldn't It is going to depend on your Locale date acceptance patterns (Tools -> Options -> Languages -- so the en-US "M/D/Y;M/D" 1. open attachment 152051 [details] 2. select the Chart object to open its OLE 3. point to the x-axis and open its context menu 4. format axis 5. in X Axis dialog, onto the Numbers tab 6. note Date is selected with 31dec99 format, and its Format Code of DDMMMYY 7. move onto X Axis dialog, Scale tab note: Minimum -> 05/01/2019 Maximum -> 11/13/2019 8. use spin button for the Minimum (e.g. starting date) down to 04/31/2019 9. use spin button for the Minimum and increase, then decrease -- What happens? Would expect there to be clean movement between May 1 and March 31 and back. That does not happen and when OK'd the chart will stretch from January 5th.
(In reply to V Stuart Foote from comment #6) Rats, of course April has just 30 days not 31.
Dear bruce, 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 https://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
Dear bruce, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Not reproducible in Calc 7.5.3.2 (X86_64)