Bug 115093 - FORMATTING: Copying date formats in cells changes date for all cells in column
Summary: FORMATTING: Copying date formats in cells changes date for all cells in column
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.0.2 rc
Hardware: x86-64 (AMD64) All
: high major
Assignee: Dennis Francis
URL:
Whiteboard: target:6.1.0 target:6.0.1 target:6.0....
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2018-01-18 15:29 UTC by landi
Modified: 2018-10-10 16:03 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
A file saved at step 8 in my description. (6.17 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2018-01-18 15:29 UTC, landi
Details
Screenshot of incorrect display of dates (77.68 KB, image/png)
2018-01-22 08:44 UTC, Alex Thurgood
Details
Problem still exists (9.61 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2018-01-25 16:33 UTC, landi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description landi 2018-01-18 15:29:17 UTC
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
Comment 1 Alex Thurgood 2018-01-22 08:44:17 UTC
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.
Comment 2 Alex Thurgood 2018-01-22 08:44:51 UTC
Created attachment 139251 [details]
Screenshot of incorrect display of dates
Comment 3 Alex Thurgood 2018-01-22 08:45:43 UTC
@Eike : this looks like some kind of locale-based number/date interpretation error - any ideas ?
Comment 4 Laurent BP 2018-01-22 22:44:08 UTC
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
Comment 5 Xisco Faulí 2018-01-23 09:40:42 UTC
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
Comment 6 Commit Notification 2018-01-24 06:56:33 UTC
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.
Comment 7 Dennis Francis 2018-01-24 06:59:29 UTC
Could someone please confirm the fix by testing the latest master ? Thanks.
Comment 8 Xisco Faulí 2018-01-24 09:59:54 UTC
(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 ?
Comment 9 Dennis Francis 2018-01-24 10:18:23 UTC
(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.
Comment 10 Commit Notification 2018-01-24 11:25:56 UTC
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.
Comment 11 landi 2018-01-24 15:35:08 UTC
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!
Comment 12 landi 2018-01-24 15:36:46 UTC
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
Comment 13 landi 2018-01-24 16:02:13 UTC
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
Comment 14 Commit Notification 2018-01-24 20:24:04 UTC
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.
Comment 15 landi 2018-01-25 16:32:09 UTC
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.
Comment 16 landi 2018-01-25 16:33:33 UTC
Created attachment 139367 [details]
Problem still exists
Comment 17 landi 2018-01-25 16:37:32 UTC
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.
Comment 18 Dennis Francis 2018-01-25 16:52:08 UTC
(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 ?
Comment 19 landi 2018-01-25 17:20:09 UTC
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?
Comment 20 landi 2018-01-25 17:31:21 UTC
(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 :-)
Comment 21 Laurent BP 2018-01-25 19:27:55 UTC
(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.
Comment 22 Xavier Van Wijmeersch 2018-01-26 18:53:58 UTC
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
Comment 23 Commit Notification 2018-10-08 08:31:27 UTC
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.
Comment 24 landi 2018-10-10 16:03:35 UTC
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