If the issue has already been rejected, perhaps I can simply nolonger use gnumeric as a spreadsheet since this issue has appeared. The work around to use Text Export (configurable) and selecting format "Preserve" does not work. It will export ########## for datafields which are not physically expanded large enough in the gnumeric UI to be fully displayed. In my use case, this is almost all of my fields.
Here is my use case: I need to open a tab delimited file, change the data in one cell, and resave the file without any other changes to the file being made (EG: translating dates from a US locale to the ISO format). Before this issue was introduced, I able able to do this with gnumeric. Fortunately I can still do this with all the other spreadsheets I have available to me (openoffice, excel), but I had preferred gnumeric the most before. Perhaps I will never be able to convince people that this issue should be corrected/changed, but this issue violates a couple tenants that I hold dear: 1) Least surprise A) The user is exporting their spreadsheet. They have right clicked on a date cell, and specifically selected the US Locale for displaying the date. Exporting to text should respect this explicit setting. B) The screen is showing the dates in US Locale. The export should respect this setting. (WYSIWYG) C) When configuring the 'Text export (configurable)', the user explicitly selected the US Locale. The exporter should respect this explicit setting. D) To avoid the files being misinterpreted, the user's settings should be respected. The user knows best. In this case, the file being generated is NOT being read by a human. The system that is accepting the file knows the users Locale, and requires them to import data files in that locale. That's pretty much the only sane way of handling currency, numerics, dates and percentages uniformly. The system *could* try their native Locale, then start randomly cycling through other parsing options, but that will likely give you improperly parsed data that the system suspected was parsed correctly. Dates may be 'simple' to identify as incorrect, but the same parsing strategy needs to be used for other datatypes aswell... which are considerably more error prone in text processing. (EG: 1,234 vs 1.234? Is this a floating point number being represented, or is that a US Locale grouping separator?) 2) Data in = Data out A) If I open a data file, and resave it without any changes, the contents should not be changed. This can be accomplished by importing the file, and detecting what format data cells are being stored as in the original text file. That part is already being done (it detects US/Locale dates as dates, and detects ISO dates as dates... and it displays them differently to the user... but both as dates. It does this be setting cell formatting to display in a different format). Then when exporting, if it respects the cell settings, it would generate identical, or nearly identical output. 3) What does everybody else do? A) Excel. Exports in the same format that comes in. B) Openoffice. Exports in the same format that comes in. C) KDE? I dunno. Attached is an example file with dates. I do hope this issue can be changed... I am a big fan of gnumeric, but alas this is a usecase I perform often, and can't risk my data being messed up. Thanks, ** Attachment added: "Tab delimited sheet w/ some US dates in it" http://librarian.launchpad.net/6724968/GnumericIssue.txt -- gnumeric does not properly export datetimes to Text format https://launchpad.net/bugs/40349 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
