You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openoffice.apache.org by bu...@apache.org on 2016/07/09 16:37:51 UTC

[Issue 127034] xlsx file: imported DateTime cells are empty (Excel 2010 compatible)

https://bz.apache.org/ooo/show_bug.cgi?id=127034

orcmid <or...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |orcmid@apache.org

--- Comment #1 from orcmid <or...@apache.org> ---
(In reply to Falcon from comment #0)
> Created attachment 85603 [details]
> xlsx with 2 datetime notation: 1 works fine and another is empty in Calc
> 
> Calc do not read DateTime in cells when date in ISO 8601 format (like
> "1961-04-12T07:55:00.123")!
> 
> By documentation (Ecma Office Open XML paragraph 18.18.11) ST_CellType cell
> type for DateTime are:
> 1. "n" and value for date is number (like "22383.32986")
> example:
>    <c r="C3" s="5" t="n">
>     <v>22383.32986</v>
>    </c>
> 
> 2. "d" and value for date is datetime (like "1961-04-12T07:55:00.123")
> example:
>    <c r="C4" s="5" t="d">
>     <v>1961-04-12T07:55:00.123</v>
>    </c>
> 
> Calc ignores the second case.
> 

That is plausible.  Which ECMA Office Open XML version are you checking?

The AOO .xlsx import filter is probably older than the time when the
clarification of date handling was improved in the ECMA/ISO specification and
in the Microsoft Excel 2010 implementation.  This would have been part of
satisfying various parties about "strict" handling of ISO dates while also
having the more-interoperable "n" case (the default in Excel, I believe).  It
is likely that the AOO filter is more "OOOXML transitional."

The actual approach in Apache OpenOffice and in ODF 1.2 OpenFormula is a
counterpart of the Excel "n" case.  

We need to check whether the equivalent of the "d" case is producible in AOO
Calc.  Then having the .xslx import filter work appropriately is an additional
challenge (along with .ods interop cases).

More analysis is needed.  Thanks for digging into this, Falcon.

-- 
You are receiving this mail because:
You are the assignee for the issue.