Created attachment 106067 [details]
Simple sheet with pivot table
Date format not transferred correct to column header in pivot-table (regression)
Windows 8.1 64-bit
LibreOffice 22.214.171.124 Danish
Create a simple table with 3 columns – Date; Description; Value – and some data.
Select the table and go to Data – Pivot-table.
Put the 'Date' in the column fields, 'Description' in row field and 'Value' in data field as sum.
The pivot-table is now made with date-format as dates serial number.
If I put the 'Date' in the row field, 'Description' in the column field there a no problem, and I can also use F12 to group the dates.
This error have no influence on pivot-tables made by earlier versions of LO – they update correct with this version of LO
Created attachment 106086 [details]
screenshot of Pivot table layout
Build ID: 652b807658a54cd2ccd04ebc6900d2cf1ce85015
TinderBox: Win-x86@39, Branch:master, Time: 2014-09-05_01:33:05
Sorry I don't have 4.3.1 available yet.
Since 4.3 we have a field named "Data".
This field is by default in column field.
His purpose is to have data by column (default) or row when having 2 (or more) fields in "Data fields".
Moving "Data" in row cure the problem.
Re-odering Column fields by dragging the "data" field after the "dato" field also works.
It seems that having this default Data field in 1st position in column fields prevents date format recognition.
Reproduced from scratch with LO 126.96.36.199 and 188.8.131.52.beta1 under Ubuntu 12.04 x86.
Not reproduced with LO 184.108.40.206
c08fd0a6e2cf014989732351c624bede765d2375 is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Mon May 12 06:03:39 2014 +0000
Author: Caolán McNamara <firstname.lastname@example.org>
AuthorDate: Sun Mar 30 21:24:11 2014 +0100
Commit: Caolán McNamara <email@example.com>
CommitDate: Mon Mar 31 09:23:16 2014 +0100
coverity#1194932 Uncaught exception
$ git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4
git bisect start 'latest' 'last42onmaster'
# good: [4fcd68ce4979f85fda4568f4b419a4b41d07345f] source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e
git bisect good 4fcd68ce4979f85fda4568f4b419a4b41d07345f
# skip: [422186458e0b4db00c7e26b54d5b631f83bcad2a] source-hash-6948bf58ce181b17f60ef81f10205ef4dac50cc6
git bisect skip 422186458e0b4db00c7e26b54d5b631f83bcad2a
# bad: [a0b33bffff9c787dce71a13b344f06ae1453026b] source-hash-02e0be069e57e724c51f23e2e31b77657a6a1d3d
git bisect bad a0b33bffff9c787dce71a13b344f06ae1453026b
# good: [db29eee512d03b1dc0139b3752bbe7931b165377] source-hash-77b6c1602aaa0bd059077765e7fabb53d9e6ddeb
git bisect good db29eee512d03b1dc0139b3752bbe7931b165377
# good: [9d57c189d74551d2b3770cc81139ea10a62e672f] source-hash-5b5e62650354788e50b44f32c22b687b2018aba9
git bisect good 9d57c189d74551d2b3770cc81139ea10a62e672f
# skip: [7ed08df7d4b9b26f20fbd161ef7283e8c5f1e619] source-hash-82332ee1fc23b6fdccaf92149c0f2fa46fcdc4d6
git bisect skip 7ed08df7d4b9b26f20fbd161ef7283e8c5f1e619
# bad: [c4b8375c4f4cd507d1bb4913f46789cf354e78a5] source-hash-9359f4747181ae93f777f224a9f64a832d5b806c
git bisect bad c4b8375c4f4cd507d1bb4913f46789cf354e78a5
# bad: [043d1114b660bf322c82b6d4af3d7a6decf410b6] source-hash-de0309581b2a539e8ccf370ff0f054a56dba1c11
git bisect bad 043d1114b660bf322c82b6d4af3d7a6decf410b6
# good: [c4e590b6482131576747491ef9e0a2f9be6071aa] source-hash-1ad901464afa29c96682bde59a12f864fccd525a
git bisect good c4e590b6482131576747491ef9e0a2f9be6071aa
# bad: [5f470f9cc992302f16a0ad8b2680725ad5beec08] source-hash-7c4783f6a2cb7598ecc48f20379dad9784541d5b
git bisect bad 5f470f9cc992302f16a0ad8b2680725ad5beec08
# bad: [c08fd0a6e2cf014989732351c624bede765d2375] source-hash-b850adf13ec8fad5f1e49c06fbb1d81a546b4636
git bisect bad c08fd0a6e2cf014989732351c624bede765d2375
# first bad commit: [c08fd0a6e2cf014989732351c624bede765d2375] source-hash-b850adf13ec8fad5f1e49c06fbb1d81a546b4636
As mentioned in comment 1, the commit where this occurs first is also the first commit where the "Data" field is in the column fields.
This began at the below commit.
Adding Cc: to firstname.lastname@example.org; Could you possibly take a look at this one? Thanks
Author: Tomaž Vajngerl <email@example.com>
AuthorDate: Sun Mar 30 21:12:27 2014 +0200
Commit: Tomaž Vajngerl <firstname.lastname@example.org>
CommitDate: Mon Mar 31 09:44:44 2014 +0200
pivot: new pivot table layout dialog
This commit adds a new pivot table layout dialog which was implemented
from scratch. Instead of custom controls this one uses list boxes
for field entries which greatly reduces the code. It also fixes
some visual and behaviour bugs and adds the possibility to edit the
(Note: reproduction on master temporarily blocked by bug 91125)
Experiencing the same problem with LO 220.127.116.11 importing a pivot table from a table within a registered DB or a cell range in the same Calc document.
Formatting the pivot table has no effect when refreshed.
System: Linux Slackware64 14.1
Add 'bisected' to Keywords as the exact commit has been determined
Migrating Whiteboard tags to Keywords: (bibisected)
Adding Cc: to Tomaž Vajngerl
Still exist on version
Version: 18.104.22.168 (x64)
Build ID: 8783ba61dfea562444cb6390e69aa8b3c5e91156
Threads CPU : 4; Version de l'OS :Windows 6.29; UI Render : par défaut;
Locale : fr-FR (fr_FR); Calc: group
Version reflects the earliest version affected. Please do no change it to a newer one
*** Bug 117814 has been marked as a duplicate of this bug. ***
Created attachment 145098 [details]
Test data for lIBREOFFICE CALC VERSION 6.062.
Note the difference between PT1 and PT2.
A possible solution is to allow user to specify custom display format for DREC under EDIT LAYOUT --> Options ---> format pivot table display for DREC
eg display only the date number instead of the full date 12/09/2018 or 43355
Dear Jens S,
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 http://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!
Version: 22.214.171.124.alpha0+ (x64)
Build ID: 71ef762f21ada8c25aad2183065478171e985e8c
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
Locale: de-DE (de_DE); UI-Language: en-US
> It seems that having this default Data field in 1st position in column fields
> prevents date format recognition.
-> removing "Data" field/or placing it after "DREC" makes date values visible
Build ID: 1:6.0.7-0ubuntu0.18.04.2
CPU threads: 2; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: nb-NO (en_US.UTF-8); Calc: group
Also reproducible with:
LibreOffice Portable Fresh 6.3.2
on Windows 10 (unfortunately I don't have more specific details here at home)
Additional comment 1:
It is possible to manually set Columns fields as date format, but the format is lost again when refreshing the pivot table.
Aditional comment 2:
When refreshing pivot table, it shouldn't remove all formattings from coloumn fields, espechially if the number of fields doesn't change (i.e. no change in data set)
I made a testcase - see attachment
Created attachment 155508 [details]
pivot table - column field doesn't show date format
Reproduced in LO 6.3
if you only select the data to create the pivot table, aka do not select the headers row, then you readily see in the "Available Fields" that date is not recognized as a date, but as an integer.
This seems to be a general problem with all the pivot table bugs related to formating loss, see metabug 103381
They are others bugs related to formating & pivot table, for instance 126557
Solving formating & pivot table issues would probably close a bunch of bug reports