Red Hat Bugzilla – Bug 489937
Default save to .csv truncates data to what is shown on-screen
Last modified: 2009-06-08 11:28:07 EDT
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.
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
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.
There is nothing to triage here, developers are apparently working on the bug already.
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
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