Download it now!
Bug 47084 - FORMATTING: FORMATTING X-axis "Time" not respected for calculated values
Summary: FORMATTING: FORMATTING X-axis "Time" not respected for calculated values
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other Windows (All)
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: BSA target:3.6.0 target:3.5.2
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-07 22:40 UTC by Rainer Bielefeld Retired
Modified: 2012-03-20 10:55 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample Document. (174.46 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-03-07 22:40 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-03-07 22:40:51 UTC
Created attachment 58155 [details]
Sample Document.

Steps how to reproduce with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit);

1. open attached "sample.ods"
2.select sheet "Wochenübersicht"
  > Chart visible , X-axis "Monday 0:10" ... "Sonntag 16:10"
   (or similar), correct with day + time information
3. double click chart
   Expected: no chagnes
   Actual: X-axis values now shown as 2,01 ... 8,86
   (or similar)

That problem is related to x-axis value calculation, the problem disappears when I copy / paste special x-axis values with "all except formula".

This sounds very similar to "Bug 43467 - axis number FORMATTING not taken automatically from cells with calculated value", but with the sample document in that bug the problem of that bug does no longer appear with 3.5.1.

I failed to reproduce the problem with a simple new document.


Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2
Comment 1 Markus Mohrhard 2012-03-09 21:17:21 UTC
You're absolutely right. The fix for bug 43467 caused this regression. I need to investigate it a bit more to understand the differences between the two implementations.
Comment 2 Not Assigned 2012-03-10 07:32:25 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ed8aae1050a0900998726e0484a032c097b6a60

take explicit number format before implicit number format, fdo#47084
Comment 3 Markus Mohrhard 2012-03-10 07:34:52 UTC
The fix for bug 43467 takes for formula cells the implicit number format but we should take an explicit number format if one is provided and only fall back to implicit number format in case it is not set.

Should be fixed now.
Comment 4 Not Assigned 2012-03-12 08:29:19 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=36e877cf80eb3b7fc092c08cdc166b75d674bf53&g=libreoffice-3-5

take explicit number format before implicit number format, fdo#47084


It will be available in LibreOffice 3.5.2.
Comment 5 Rainer Bielefeld Retired 2012-03-20 10:55:47 UTC
Yes, works fine with parallel installation of "LOdev 3.5.2rc0+  [Build ID: ec752de-73cb0b8-f269e46] Win-x86@6-fast pull time 2012-03-19 11:08:23 – WIN7 Home Premium (64bit), thank you!