To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=62797


User fs changed the following:

                  What    |Old value                 |New value
================================================================================
               Assigned to|nn                        |oj
--------------------------------------------------------------------------------
            Ever confirmed|                          |1
--------------------------------------------------------------------------------
                    Status|UNCONFIRMED               |NEW
--------------------------------------------------------------------------------
                   Summary|wrong handling of date    |wrong handling of date
                          |from Calc when copy&paste |from Calc when copy&paste
                          |to Writer/Web or Base     |to Base as HTML
--------------------------------------------------------------------------------
          Target milestone|OOo Later                 |OOo 2.0.3
--------------------------------------------------------------------------------




------- Additional comments from [EMAIL PROTECTED] Tue Mar 28 00:51:49 -0800 
2006 -------
fs->oj: at least for the HTML part, this can probably be fixed:
OHTMLReader::NextToken evaluates the "sdval" attribute of a table cell. Now this
contains the (number-formatter-dependent) numeric value only, which cannot
intepreted without having the number formatter - and its NullDate, in
particular. Since we do not have this formatter, I suggest that
OHTMLReader::NextToken uses another approach:

the "sdnum" attribute of the table cell describes the number format of the
string. We should use to to translate the cell content into a numeric value. If
we then not only remember the textual representation (m_sNextToken), but the
already-converted numeric representation, together with the number format, we
should be on the safe side (and also spare
ODatabaseExport::insertValueIntoColumn some work).

Since I consider this data corruption (the pasted data is different from the
original data) during collaboration of OOo applications, I target it for the
next maintainance release.


fs->regina: I'm adjusting the summary to reflect that this is about HTML and
Base only. Sorry, but there are reasons [1] why multiple problems per issue are
difficult to handle. At least the Writer/Web part is completely different from
this one here (and much less severe, IMO). The Base/RTF part is probably (after
I examined the source) also different, and also less severe IMO since the
default format for pasting is HTML. So, if you want those other incarnations to
be fixed, too, I encourage you to submit new issues. Sorry and thanks :)

[1] http://qa.openoffice.org/issue_handling/basic_rules.html#one_per_issue

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to