Created attachment 139190 [details] A file saved at step 8 in my description. 1. Open a blank spreadsheet. 2. Put at least 100 random dates in separate cells of column A, using format YYYY-MM-DD. I was unable to reproduce the problem with less random dates; it seems to only occur when there’s at least 100 cells with dates. 3. Select column A and format cells as a Date, using format YYYY-MM-DD. 4. Select column B, which is currently blank, and format cells as Date, using format MMM D, YYYY. 5. Make cell B1 equal to A1 using formula: =A1 6. A1 will now look like, for example, 2015-10-15; B1 will look like October 15, 2015. (You might need to widen column B) 7. Grab the lower right handle of cell B1, and drag it down to copy its formula so that all the cells in column B match the cells in column A. 8. Save the file as xlsx, then close and re-open it. The test file I’ve attached is saved at this point. 9. Go to the last cell in column B that has data. Drag its handle down one cell to copy its formula. 10. The problem will now present itself: all the cells in B are now duplicates of the last cell in that column (the one you just dragged on.) 11. Further, if you look at the cell formatting in any cell of column B, you’ll see that it’s now changed to be MMM D", "YYYY (it’s added those quote marks) 12. Also, if you copy/paste the last cell in column B rather than drag-copy, the same problem occurs. 13. Regression test: It does NOT occur in version 5.4.4002
I can reproduce this even with a list of sequential dates, having set the language of cell formatting to en-US, when testing with : Version: 6.1.0.0.alpha0+ Build ID: dd758f54fa5ea1ecd3d793bcea999d771010ff00 CPU threads: 4; OS: Mac OS X 10.13.2; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded I didn't need to save to Excel or even input more than 100 dates. Simply, dragging and copying the value of B1 down to the B100 was enough to change the displayed date values in both column A and column B. I have enclosed a screenshot of what I see.
Created attachment 139251 [details] Screenshot of incorrect display of dates
@Eike : this looks like some kind of locale-based number/date interpretation error - any ideas ?
There is no need to use any specific format. It does not seem to be a format problem. I reproduce with 100 and more values in column A. I do not reproduce 99 values. My procedure: 1. Enter a value in A1 2. In B1: =A1 3. Extend values in column A with sequential dates to line 'n' 4. Double click on the handle of B1 If n=99, values are the same in column A and B as expected. If n>99, all displayed values in column B are equal to the nth value of column A. Shift+Ctrl+F9 has no effect of displayed value. If in C1: =B1, then C1 contains the displayed value of B1, not A1 as expected. Changing format of B1:B100 displays same value. Changing value in Ai (i != n) has no effect (even with Shift+Ctrl+F9). Changing value in An requires Shift+Ctrl+F9 to update all values in column B. If formula in column B is extended with more values than in column A, then contents in this extra cells are as expected: 0 or 30th December 1899 Changing start cell to H7 instead of A1 has no modification of the bug. Cells A1 and B1 do not need to be contiguous. Version: 6.0.0.2 Build ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd Threads CPU : 8; OS : Linux 4.13; UI Render : par défaut; VCL: gtk2; Locale : fr-FR (fr_FR.UTF-8); Calc: group
Regression introduced by: author Dennis Francis <dennis.francis@collabora.co.uk> 2017-11-15 16:14:32 +0530 committer Dennis Francis <dennis.francis@collabora.co.uk> 2017-11-21 16:09:43 +0530 commit fbcdce22bce6d6d1ba5a9e90b642ea08fc09916a (patch) tree 66c74ad6f3582f64b95972837bef70f96ff36192 parent 765c8d8b56f5199c87291a02f6324a70661d55ec (diff) Avoid ScTokenArray thrash Allocate ScTokenArray object only once per worker thread, fill it for the first row/cell and reuse them for subsequent rows/cells if possible. Bisected with: bibisect-linux64-6.0 Adding Cc: to Dennis Francis
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff166845fa5ed178a97b54bb2deef4beb0cf3bdf tdf#115093 : Do not reuse singleref tokens... It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Could someone please confirm the fix by testing the latest master ? Thanks.
(In reply to Dennis Francis from comment #7) > Could someone please confirm the fix by testing the latest master ? Thanks. Verified in Version: 6.1.0.0.alpha0+ Build ID: e0e19de6eccf83caa82013ca2fefbfcc114816a0 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded 6-0-0 is going to be tagged later today, could you please cherry-pick it to that branch to see if it still makes it in ?
(In reply to Xisco Faulí from comment #8) > Verified in > > Version: 6.1.0.0.alpha0+ > Build ID: e0e19de6eccf83caa82013ca2fefbfcc114816a0 > CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded > > 6-0-0 is going to be tagged later today, could you please cherry-pick it to > that branch to see if it still makes it in ? Sure, the patch for 6-0 branch is at https://gerrit.libreoffice.org/#/c/48478/ I will push as soon as it finishes.
Dennis Francis committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1c6244f1faaefb6a5198c79c00849924ac2e91c2&h=libreoffice-6-0 tdf#115093 : Do not reuse singleref tokens... It will be available in 6.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Using my original test file, the problem is still there. But that test file has the badly formatted dates in column B (MMM D", "YYYY). Creating a new test file from scratch, I can confirm that the bug appears to be gone. I tested several ways and was unable to reproduce the bug. When I drag the handle down in column B to extend the formatting and formula, the date format is correct (MMM D, YYYY, no quotes this time). Thanks for the quick fix to this. The LO community is great!
PS. I was using: Version: 6.0.1.0.0+ Build ID: ada232a67fbb3acf60b104a4916719dbdb891819 CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:libreoffice-6-0, Time: 2018-01-23_23:43:30 Locale: en-US (en_US.UTF-8); Calc: grou
Also verified and confirmed fixed in: Version: 6.1.0.0.alpha0+ Build ID: 6fc9d4a482ab50a1bf8fefb1dae2a6ded3c7e3dd CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-01-24_04:46:24 Locale: en-US (en_US.UTF-8); Calc: group threaded
Dennis Francis committed a patch related to this issue. It has been pushed to "libreoffice-6-0-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de93c097e729f70c63de02e3d6b1d596fac7c5f6&h=libreoffice-6-0-0 tdf#115093 : Do not reuse singleref tokens... It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I hate to say this, but I don't think it's fixed after all. In doing more testing, the problem is still there, but slightly different now. Instead of changing column B to be all the same date, it changes Column B to be groups of the same dates. I'm uploading an attachment. Try dragging the handle of the bottom populated cell in B and watch what happens.
Created attachment 139367 [details] Problem still exists
I'm using: Version: 6.1.0.0.alpha0+ Build ID: 6fc9d4a482ab50a1bf8fefb1dae2a6ded3c7e3dd CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-01-24_04:46:24 Locale: en-US (en_US.UTF-8); Calc: group threaded And the problem only presented itself after closing LO and re-starting it. When working with the file in a single session, such as creating it from scratch, the problem didn't happen.
(In reply to landi from comment #17) > I'm using: > > Version: 6.1.0.0.alpha0+ > Build ID: 6fc9d4a482ab50a1bf8fefb1dae2a6ded3c7e3dd > CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; > TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-01-24_04:46:24 > Locale: en-US (en_US.UTF-8); Calc: group threaded > > And the problem only presented itself after closing LO and re-starting it. > When working with the file in a single session, such as creating it from > scratch, the problem didn't happen. I can't seem to reproduce. I think the version you are using is missing the patch (deduced from the timestamps), could you please try with the one build today ie 25th Jan 2018 ?
Thanks. I assumed the one I had was patched, but I guess not. I downloaded the following and it seems to work: Version: 6.1.0.0.alpha0+ Build ID: cae452a167b78d8dc164059db8a9fbe1eb3d521d CPU threads: 8; OS: Mac OS X 10.13.2; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-01-25_06:25:26 Locale: en-US (en_US.UTF-8); Calc: group threaded I've tried different ways to break it but the problem doesn't seem to be reappearing. HOWEVER: When I look at the date format, it's still showing MMM D", "YYYY (with those strange quotes in there). Is that a problem? Why does it add those and will it conflict with anything?
(In reply to landi from comment #19) I'm guessing those quotes characters are escape characters for the comma and space, right? Anyway, sorry for the fire alarm but I think the bug really is patched :-)
(In reply to landi from comment #19) > HOWEVER: When I look at the date format, it's still showing MMM D", "YYYY > (with those strange quotes in there). Is that a problem? Why does it add > those and will it conflict with anything? This addition is done on purpose to avoid conflict when detecting thousand or decimal separator, especially if you export to alien format.
tested with both attachment's and its working Version: 6.1.0.0.alpha0+ Build ID: 2cbcaa58b9fdbe78119b43a2a4404bebbb3fcebd CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group threaded home build 20180126
Dennis Francis committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7bafe2441480e2b88d999b30b7f117f05e72c3b3&h=libreoffice-6-1 tdf#119904 : Generalize the fix for tdf#115093 It will be available in 6.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have tested this on the following, and it appears to be fixed. Version: 6.1.3.0.0+ Build ID: c523d9556a354e1afac3203b6f1c8b75a2f7d2f0 CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:libreoffice-6-1, Time: 2018-10-09_06:32:49 Locale: en-US (en_US.UTF-8); Calc: group threaded