Created attachment 164546 [details] Shows the incorrectly calculated series output for the date input start (8/17/2020) and end (8/23/2020) values Description: title Steps to reproduce: 1. Select 7 rows (can be any amount of rows but 7 for the purposes of this reproduction) in a column 2. Open the fill series dialog via Sheet->Fill Cells->Fill Series... 3. Set the Series Type to Date and set the Time Unit to Day 4. Set the start value as 8/17/2020 and the end value as 8/23/2020 and keep the increment as 1 5. Press ok Expected behavior: A series of values will be incremented starting from 8/17/2020 and ending at 8/23/2020. Actual behavior: A series of values will be incremented starting from 44060 and ending at 44066. This is annoying as I specified dates to be incremented instead of some number. Reproducible: Always User Profile Reset: No* *I tested this with 6.4.6 on Linux and 7.0.0.3 Windows 10, and the same behavior persists on both. Notes: If the first cell selected before getting into the fill series dialog has a date (such as 8/17/2020) and then set the time unit to day (as it automatically gets set to month) and dialog is filled out the same as the reproduction steps, then the date series will be properly formatted and incremented. The attached file attempts to increment the date series with each of the series types with similar results. I'm not necessarily concerned with the columns other than Date, but I thought it would be useful to show what other types may increment similar output in the event that they aren't supposed to increment that output. Version information (for the Windows 10 install): Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
The data is *calculated* OK, so the description is wrong when refers to incorrect *calculation*. E.g., 44065 is the serial date for 2020-08-22. If you apply the Date formatting to the resulting cells after the fill, you will get the desired display. So the issue seems to be that the function does not apply the cell format itself?
repro, - setting new @Mike Kaganski: 'So the issue seems to be that the function does not apply the cell format itself?' - that's it, changing 'subject', may be 'locale' or 'date acceptance pattern' dependent? Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 62dff2844b0bf1d1bcb8eb4d6db529ef4a31bee4 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc:
Dear Yetoo Happy, 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
(In reply to QA Administrators from comment #3) This is still an issue. Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Code pointer: https://opengrok.libreoffice.org/xref/core/sc/source/core/data/table4.cxx?r=4790ef5c#2508 Unfortunately, I have not idea how to set the format of a cell.