Description: When applying a conditionnal format, date data is displayed as a decimal number. Steps to Reproduce: 1.open the test file 2.look at red cells and see that the data inside is a date. 3. Actual Results: Wrong format Expected Results: Date format Reproducible: Always User Profile Reset: No Additional Info: Tested on Version: 7.2.2.2 / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded works with Version: 6.2.8.1 Build ID: 815fe723fb0e60e4a39ff860f907cc63980a0232 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded doesn't work with Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded it works with Version: 6.1.4.1 Build ID: 25073d18caee244880112e52c4a7e71f6081b3a9 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk2; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded So regression is between 6.2.8.1 and 6.3.6.2
Created attachment 176601 [details] Test document ods
Version : 6.3.3.2 is not affected Version: 6.3.4.1 is affected Build ID: a21169d87339dfa44546f33d6d159e89881e9d92 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded So think the false commit is in this version.
Confirming with version: Version: 7.3.0.0.beta1+ / LibreOffice Community Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Seems to have started with: https://git.libreoffice.org/core/+/0b9e0f20763f0e723d66f31aee85205deec9f6f8 author Eike Rathke <erack@redhat.com> Sun Oct 27 00:25:28 2019 +0200 committer Caolán McNamara <caolanm@redhat.com> Wed Oct 30 18:04:18 2019 +0100 tree 519cc33af5493e8c97c750395919fd628f10c2da parent fe7deff845c39a351a92b8e01168a527fc237a9b [diff] Resolves: tdf#117715 Conditional format takes precedence; reverts tdf#93300 Adding CC to: Eike Rathke
Created attachment 176609 [details] The example document in 6.3 and 6.0.7 (good)
I can also reproduce with 7.3.0 Beta1. However, after examining the attached spreadsheet and reading the bibisected commit in comment 3, I'd like to argue that this is the result of an intentional change and expected behavior, and the user should change their document instead. The column J of attachment 176601 [details] has "Default" cell style, which doesn't seem to set the numbers format. So likely the column is set to "Date" format with direct formatting (didn't check the XML source to confirm). Then on top of it two conditional formatting are applied, one set to apply "cf110" cell style (green background), the other "cf111" (red background). Now if we look at the "cf110" and "cf111" cell styles closely, "cf110" has the numbers format set to "Date", the same as direct formatting; however "cf111" has the numbers format "Number", different from the direct formatting's "Date". Therefore after commit 0b9e0f20763f0e723d66f31aee85205deec9f6f8, the "cf111" conditional formatting takes precedence, overwriting direct formatting's "Date" format and displays "Number" format instead. Modifying "cf111" cell style and explicitly set numbers format to "Date" will get the same displaying result as pre-6.3.4. IMHO bug 93300 should be reopened and this can be marked as duplicate of that one.