Bug 489937

Summary: Default save to .csv truncates data to what is shown on-screen
Product: [Fedora] Fedora Reporter: Manuel Morales <mmorales>
Component: openoffice.orgAssignee: Caolan McNamara <caolanm>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: caolanm, mcepl, mcepl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-08 15:28:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Manuel Morales 2009-03-12 15:48:17 UTC
Description of problem: 
When saving a file to .csv in oocalc, the default behavior is to "Save cell content as shown". The effect is to truncate numeric values to their displayed values. This seriously limits the utility of oocalc for scientific/statistical applications where .csv files are a standard for data exchange.


Version-Release number of selected component (if applicable):
openoffice.org-calc-core-3.0.1-15.2

How reproducible:
Always.

Steps to Reproduce:
1. Type 1.11111 in a cell
2. Save as test.csv
3. Re-open file -> number is converted to 1.11
  
Actual results:
To maintain data integrity, it is necessary (always) to select File->Save As, then check the "Edit filter settings" option, and finally deselect the "Save cell content as shown" option.

Expected results:
Have the "Save cell content as shown option" unselected as the default, or allow it to be a user-selectable default.

Additional info:
I have set the severity of this bug to high because the practical consequence of the current default behavior is data loss/corruption.

Comment 1 Caolan McNamara 2009-03-12 16:29:04 UTC
Someone gets screwed either way, either you get what you see on screen, which is what you don't want in this case, or you don't get what you see on screen, which screws someone else

http://specs.openoffice.org/calc/filters/csv/save-to-csv.odt

Maybe the best thing is to simply make the chosen setting persistent, so once set they stay stuck

Comment 2 Manuel Morales 2009-03-12 21:20:40 UTC
Making the change persistent is fine. However, I still think the default should be changed. The example given in the spec describes the following justification for having the current default (i.e., Save cell content as shown):

"a currency value, $910.00 is saved as simply 910 (more serious; [because] it has become a simple number/integer."

Nevertheless, this change doesn't affect the *value*, just the formatting and the original format can be restored. In contrast, truncating 1.23456789 to 1.23 permanently corrupts the data. It can not be restored once the program has been closed.

Comment 3 Matěj Cepl 2009-05-12 19:29:24 UTC
There is nothing to triage here, developers are apparently working on the bug already.

Comment 4 Caolan McNamara 2009-05-12 21:44:22 UTC
Its debatable whether is really is a "bug" as it works by design. Though a better design is called for. I'm in two minds as whether to close it as upstream, or direct effort towards helping the upstream effort through to 3.2

Comment 5 Caolan McNamara 2009-06-08 15:28:07 UTC
got to be honest here, not going to get the time to do it myself, so punting to the upstream issue which is targeted for 3.2