GNOME Bugzilla – Bug 671860
time shift in meta data roundtrip
Last modified: 2012-03-20 13:11:10 UTC
./ssconvert ../samples/excel/statfuns.xls /tmp/statfuns.ods cd ../test ./ttt.pl /tmp/statfuns.ods | less welinder@anemone:~/gnome/gnumeric/test> cat ttt.pl #!/usr/bin/perl -w # ----------------------------------------------------------------------------- use strict; use lib ($0 =~ m|^(.*/)| ? $1 : "."); use GnumericTest; &message ("Check the xls exporter."); &test_exporter ($ARGV[0]); This does statfuns.ods->gnumeric and compares with statfuns.ods->ods->gnumeric, Results should be identical. I see: - <dc:date>1999-10-27T08:16:13Z</dc:date> + <dc:date>1999-10-27T09:16:13Z</dc:date> - <meta:print-date>1999-10-27T08:11:59Z</meta:print-date> + <meta:print-date>1999-10-27T09:11:59Z</meta:print-date> (Several) - <gnm:Style [...] Format=""+""> + <gnm:Style [...] Format=""+"#">
The corresponding test for objs.ods shows: - <font color="0:0:0:FF" font="Tahoma 8" auto-scale="1"/> + <font color="0:0:0:FF" font="Tahoma Bold 8" auto-scale="1"/>
Scratch that last one. There are issues, but not that one.
- <dc:date>1999-10-27T08:16:13Z</dc:date> + <dc:date>1999-10-27T09:16:13Z</dc:date> If I open the file in question in Gnumeric, I see Last Modified: 1999-10-27 01:16:13 which should be in local time...
../src/ssconvert ../samples/excel/objs.xls /tmp/ooo.ods ../src/ssconvert /tmp/ooo.ods /tmp/ooo.gnumeric Using exporter Gnumeric_XmlIO:sax Unexpected element 'text:line-break' in state : document-content -> body -> spreadsheet -> table -> table-row -> table-cell -> annotation -> p -> span -> span -> span -> span -> span -> span Unexpected element 'text:line-break' in state : document-content -> body -> spreadsheet -> table -> table-row -> table-cell -> annotation -> p -> span -> span -> span -> span -> span -> span (/home/welinder/gnome-src/gnumeric/src/.libs/ssconvert:21790): GLib-CRITICAL **: g_base64_encode_step: assertion `in != NULL' failed
Regarding comment #4: The "Unexpected element" is fixed. The CRITICAL happens in the .gnumeric output:
+ Trace 229903
Unfortunately I can't replicate the original problem: aguelzow@kirkman:~/git/gnumeric/test$ ./ttt.pl /tmp/statfuns.ods ------------------------------------------------------------------------------- ttt.pl: Check the xls exporter. | Using exporter Gnumeric_XmlIO:sax | | ** CRITICAL **: go_conf_add_monitor: assertion `node || key' failed Trace/breakpoint trap | Using exporter Gnumeric_OpenCalc:odf | | ** CRITICAL **: go_conf_add_monitor: assertion `node || key' failed Trace/breakpoint trap | Using exporter Gnumeric_XmlIO:sax | E /home/aguelzow/git/gnumeric/test/statfuns-new.ods: No such file or directory gzip: statfuns.gnumeric.gz: No such file or directory zcat died due to signal 1
Note that the issue with: - <dc:date>1999-10-27T08:16:13Z</dc:date> + <dc:date>1999-10-27T09:16:13Z</dc:date> - <meta:print-date>1999-10-27T08:11:59Z</meta:print-date> + <meta:print-date>1999-10-27T09:11:59Z</meta:print-date> (Several) is not due to the openoffice plugin. Exactly the same can be observed by comparing: xls->gnumeric with xls->gnumeric->gnumeric
SO, the only ODF specific roundtrip issue remaining here is: - <gnm:Style [...] Format=""+""> + <gnm:Style [...] Format=""+"#">
Hmm, looking at C4 the xls file has the format 0.00E+00 after the first save as ods file this has become "+" and after the second save: "+"# So there is more than just a round trip problem here.
The 0.00E+00 --> "+" issue has been fixed in goffice.
The format "+" is currently exported to ODF as: <number:number-style style:name="ND.0"><number:text>+</number:text><number:number number:decimal-places="0" number:display-factor="1" number:grouping="false" number:min-integer-digits="0"/></number:number-style> when it should be: <number:number-style style:name="N110"><number:text>+</number:text></number:number-style>
The issue described in comment 11 is now fixed in goffice. The issue described in comment #7 remains and is really a libgsf issue.
I am reassigning this issue to libgsf since the remaining issue is clearly in libgsf.
I observe: gsf_timestamp_from_string 2012-03-18T19:59:04Z --> 1332125944.000000 off: -21600.000000 gsf_timestamp_from_string 2012-03-18T19:58:30Z --> 1332125910.000000 off: -21600.000000 gsf_timestamp_as_string: 1332104344.000000 --> 2012-03-18T20:59:04Z gsf_timestamp_as_string: 1332104310.000000 --> 2012-03-18T20:58:30Z so gsf_timestamp_from_string translates 2012-03-18T19:59:04Z to 1332125944-21600 = 1332104344 later gsf_timestamp_as_string translates 1332104344 back to 2012-03-18T20:59:04Z. One of these translations is off by an hour.
welinder@anemone:~> TZ=GMT perl -e 'print scalar localtime 1332104344, "\n";' Sun Mar 18 20:59:04 2012 welinder@anemone:~> TZ=GMT perl -e 'print scalar localtime 1332104310, "\n";' Sun Mar 18 20:58:30 2012 It looks like gsf_timestamp_as_string works just fine.
I have a tentative patch based on GDateTime.
re libgsf (time shift problem): This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. re goffice/gnumeric parts: This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.