Still exist in 3.4.1. Not occurring in 3.3.3

Still exist in 3.4.2, I suppose this is serious regression in compare to previous branch of Libreoffice 3.3.

(In reply to comment #2)
> Still exist in 3.4.2, I suppose this is serious regression in compare to
> previous branch of Libreoffice 3.3.

Still exists on 3.4.3. I have reported bug 40299 before seeing this, but got about as much attention as you did.

*** Bug 40299 has been marked as a duplicate of this bug. ***

Is this bug is bothering only 2 persons? Is is very annoying, because it makes complicate work with previously created files and I'm sure that the solution should be quite easy.

Dear developers,

would it be possible to get a reaction on this bug (Any kind of reaction) before the code freeze for 3.4.4?

I just found a workaround which seems to work for me (and probably explains why this "bug" is ignored by the developers).
You have to change in the style "Pivot Table Category" the number format to text. 
This leads to the desired behavior in my case.

Nonetheless, in LibO 3.3 the default setting for this style is the same as in LibO 3.4, but the behavior is different. I think that this should at least be documented.

I am struggling with this bug as well. Base shouldn't send everything to calc as text and let calc try to decide for itself what each field is (date, time, text or float). Base already has this information, there is no need to try to redetect it, and it's even worse if calc does it wrong because it makes too much assumptions to "make your life easier"... The cause seems to be the same that causes this bug I reported myself: https://bugs.freedesktop.org/show_bug.cgi?id=41577

I can assure you that more than 2 people care about this kind of bug, everybody here at my company (an engineering company that uses libreoffice and therefore increases the software's market-share) is losing hair over this.

Just tested Nikos 's idea, and as I expected, it works to prevent data like 22.1 being converted autmatically to 22/01/11, but it still doesn't work in my case because I need that 22.1 to be a number so I can do math with it. With Nikos's idea I can at best prevent calc from converting things the wrong way automatically, but I would need still to convert data to numbers AGAIN (it was numbers in the first place...). And I can't see any whay of doing this sustainably: I would have to replace the dot with a comma so "22.1" became "22,1" and only then put that string into a =value() formula. It is complicated, by definition it shouldn't be necessary and if I ever need these files to be opened by a client/worker in a place where the locale setting uses dot as decimal separator instead of comma, I would need to change all these formulas, right? And would need to know which locale setting the person who will open the file has. Or not? It's just my opinion, but I think the logical calculations (that have nothing to do with place or locale) in a spreadsheet should not depend upon the PLACE or the LOCALE where the spreadsheet is being used in order to work.

Unfortunately, I must revise my comment that changing the "Pivot table category" style solves the problem in my case, since this is the case only in a very limited number of cases. In other cases the pivot table just returns the numeric value corresponding to the date it interprets in my data.

I am very disappointed by this behavior of the software. One of the reasons I moved to Openoffice (back in 2.2) was that the distinction between different data types (strings vs. numbers) was clearer than in the software we used till that time. Even though I understand the urge to keep up with a market leader as well as the necessity to maintain (or achieve) a high level of compatibility, this is a point where the openoffice/Libreoffice approach up to version 3.3 was clearly superior.

There are at least 4 bugs describing this behavior, which is creating serious problems to advanced users, and I have not found a single reaction from a developer thus far.

I found the same, that formatting of datapilot column headers do solve the problem. I think that LibreOffice 3.3.3 version or earlier has fully functioning data pilot. The 3.4 branch has strange compatibility problems when working with complex documents containing array functions.
I can only add that the data pilot, or pivot table now, is the most important feature of calc making it different from Gnumeric or Koffice spreadsheet application.

(In reply to comment #11)
> I found the same, that formatting of datapilot column headers do solve the
> problem. I think that LibreOffice 3.3.3 version or earlier has fully
> functioning data pilot. The 3.4 branch has strange compatibility problems when
> working with complex documents containing array functions.
> I can only add that the data pilot, or pivot table now, is the most important
> feature of calc making it different from Gnumeric or Koffice spreadsheet
> application.

sorry for mistake:

formatting of datapilot column headers do not solve the problem.

As expected,

problem persists on 3.4.4, rendering pivot table unusable for any serious work.

To my surprise another popular spreadsheet, which usually does not respect differences between strings and numbers, does not show this strange behavior.

PLEASE return to the 3.3 datapilot/pivot table functionality in 3.5.

3.4.4RC1 that is

I believe I've already fixed this one for 3.5.

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

Thank you!