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
