I can confirm this although my skills with getpivotdata are limited.

Marking: 

New (Confirmed)

Version (3.6.3.2) - this is oldest confirmed version, I'm sure it has been like this forever but I can't test back before this version

Minor (I guess in very specific situations you might be prevented from making high quality work but in 99.9% of the cases this just makes it a little annoying to get results)

Lowest (Pivot tables in general aren't that common, getpivotdata is even less common, coupled with the fact that there is a workaround (change data format), makes this lowest priority.


Thanks for reporting, we'll see what we can do about this :)

Hi Joel,

the workaround is there, but:

- No where you can know about this limitation, so I have spent much time to know how to do it. If it is no possible to solve for 4.x release, maybe we need to mention on the help of the function.

- Breaks the share between different languages, because you need to use the TEXT(date;format) function with dates, and the second parameter of the function is not updated as the number cell format, when one use other local settings. Or combine several function to get the text.

- The GETPIVOTDATA() function, is very powerful, even of course need understand how it works, but if you can not make it works without know or understand why, less people are going to get the benefit of use it.

- And will be more easy, when IFERROR() function can be applied.

- For me the more important is that I can organize the data without worried about the Pivot table format, and using cell references inside the function to set the field and the conditions.

- But I fear that the problem is not with the function but with the way how the data are in the Pivot table, so not easy to solve.

- Or it was developed to work so. Then not a bug and the workaround is the right way. Who knows?

- As I can see in ML Ask Forums, many people use calc as a little database or to retrieve data from a database, and Pivot table with a couple of enhancements would be one of the more important tools in calc.

Thanks for the updated information, you are right in that I don't know if this is how it was built or what, I do suspect that it's not a really simple fix.

As for priority being lowest, I'm sure that you know that you are in the top 10% of users just with the fact that you know about pivot tables and how to use functions like getpivotdata. Just because it is lowest priority doesn't mean that it won't get fixed, many things go into the order of how bugs/enhancements are taken care of, only one of which is priority. Other factors can be if a developer sees the bug confirmed and knows the code well already, or if a developer just thinks that they want to take it on just because. 

I use pivot tables quite frequently but am aware that this isn't the case for the vast amount of users and because of this, it should be treated as a low priority compared to a bug like this: https://bugs.freedesktop.org/show_bug.cgi?id=34423 where a lot of users insert images and want to play around with rotation.

Thanks again for the update, don't think we'll ignore this one just because it has a "lowest" priority :)

The issue is also in AOO.

** Please read this message in its entirety before responding **

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 on a currently supported version of LibreOffice (5.0.4 or later)  https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

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)

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: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17

Created attachment 122049 [details]
Sample file review

The issue remains.

Attached the sample file reviewed to make more visible the issue.

Matching dates was fixed for bug 35247. Note however that,
a) locale dependent text constructs like those in cell A12 will not work
   in other locales that have a different D/M/Y order or different
   separators or even format keywords.
b) after loading the document in a UI that uses different localized
   function names, the pivot table needs to be refreshed (context menu
   on pivot table, Refresh) because the, in this case, stored Data Field
   name "Soma - VALUE" in F3 does not match a, for example, "Sum
   - VALUE" if loaded in an English UI.
   This is a known shortcoming to be addressed in further work.

*** This bug has been marked as a duplicate of bug 35247 ***