This problem that was observed with saving this sheet to ods (using lots
of memory and cpu time) has been confirmed fixed.  That was bug 634135.

What was the fix?

This does not look like a gnumeric bug. 

For starters this is not a valid ODF file. (Run it through Oracle's validator at http://tools.odftoolkit.org/odfvalidator/ to see that.)

Moreover in the file for '1qt Insp'!C2 there is:

<table:table-cell table:style-name="ce35" office:value-type="float" office:value="40182"><text:p>01/04/10</text:p></table:table-cell>

If this cell contains a date we should have office:value-type="date" and office:value="2010-04-01". (As a minimum there is a OpenOffice bug here.

For the column we have
<table:table-column table:style-name="co10" table:default-cell-style-name="Default"/>
The row has <table:table-row table:style-name="ro4">, so the style that applies to this cell is given by table:default-cell-style-name="Default".

Since the cell has a style-name specified we will be using that style "ce35".
Style "ce35" of family "table cell" is:
<style:style style:name="ce35" style:family="table-cell" style:parent-style-name="Default" style:data-style-name="N136"><style:table-cell-properties style:diagonal-bl-tr="none" style:diagonal-tl-br="none" fo:border="0.0138in solid #000000"/><style:text-properties style:use-window-font-color="true" style:text-outline="false" style:text-line-through-style="none" style:font-name="Arial1" fo:font-size="10pt" fo:font-style="normal" fo:text-shadow="none" style:text-underline-style="none" fo:font-weight="normal" style:font-size-asian="10pt" style:font-style-asian="normal" style:font-weight-asian="normal" style:font-name-complex="Arial1" style:font-size-complex="10pt" style:font-style-complex="normal" style:font-weight-complex="normal"/></style:style>

For us the interesting part is style:data-style-name="N136". In styles.xml we have the named data style:

<number:text-style style:name="N136"><number:text-content/><style:map style:condition="value()&gt;=0" style:apply-style-name="N136P0"/></number:text-style>

Note that according to the current ODF1.2 draft: "The <number:text-style> element defines a style for displaying text." Since we are not displaying text, but a floating point number, this style does not apply. So there is another OpenOffice bug here since the data style with name N136 and family table-cell should apply to floats.

Ignoring this and digging deeper we encounter the conditional style <style:map style:condition="value()&gt;=0" style:apply-style-name="N136P0"/>. [Note that we are apparently not reading this conditional style.]

Data-style N136P0 is
<number:date-style style:name="N136P0" style:volatile="true"><number:month number:style="long"/><number:text>/</number:text><number:day number:style="long"/><number:text>/</number:text><number:year/></number:date-style>
So this would give a date.

To recap:
The file specifies a float not a date for the cells in question.
The style for the cell only specifies a data-style for text (not for floats or dates).
That data-style for text contains a conditional style which in fact renders a date.

So to show a date we need to ignore some OpenOffice bugs. Of course there is the problem that some other generator may create files that depend on us not ignoring these bugs. Note that "The <number:text-style> element defines a style for displaying text." is normative text (ie. not just a note.) So if we use that style to decide that we are rendering a date we would be technically in violation of the ODF1.2 draft standard. So I tend to say that this is not a Gnumeric bug.

Frank, the fix to the long saving time, was
http://git.gnome.org/browse/gnumeric/commit/?id=b16d9174b1d5d95407eba6f897de72a195013d87

Created attachment 175555 [details]
Small sample of same thing

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.

I appreciate your quick response. If I run across anything else I will pass it along in the future.