[Libreoffice-bugs] [Bug 44453] FILESAVE FILEOPEN .xls: EXCEL Leap year bug has to be mentioned

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=44453

--- Comment #12 from Mike Kaganski <mikekaganski at hotmail.com> ---
Created attachment 175303
  --> https://bugs.documentfoundation.org/attachment.cgi?id=175303&action=edit
Excel 2016 showing dates before 1904 using base-1904

(In reply to Eike Rathke from comment #3)
> If dateCompatibility=true and date1904=true, the date base is 1904.
> Presumably Excel does not calculate dates before 1904-01-01 so the
> 1900-02-29 problem would be moot (could someone verify?)

What Excel does with pre-epoch dates in this mode is just hilarious - see the
screenshot. Anyway, as you expected, the problem for pre-1904 would not occur.

Wrt dateCompatibility attribute of workbookPr:

there is also [MS-OI29500] "Office Implementation Information for ISO/IEC 29500
Standards Support" document, which is implementation notes for MS Office. It
tells about the mentioned attribute [1]:

> g. The standard states that the dateCompatibility attribute determines whether
> the date base should be treated as a compatibility date base or should support
> the full date range of [ISO-8601].
> 
> Office ignores the dateCompatibility attribute, and always uses a compatibility
> date base.
> 
> This note applies to the following products: Office 2010, Office 2010 Server,
> Office 2010 SP1.
> ...
> j.   The standard states that the dateCompatibility attribute determines whether
> the date base should be treated as a compatibility date base or should support
> the full date range of [ISO-8601].
> 
> Office ignores the dateCompatibility attribute. If workbook at conformance equals
> "strict", the 1900 date system is used. Otherwise the 1900 compatibility date
> system is used. Excel does not support negative serial numbers.
> 
> This note applies to the following products: Office 2013 Client (Strict), Office
> 2013 Server (Strict), Office 2013 Client (Transitional), Office 2013 Server
> (Transitional).

And indeed, the later version of ISO/IEC 29500-1 (namely, 2016 [2]) does not
mention "dateCompatibility" attribute at all.

Now the standard [2] defines workbook at conformance in "18.2.27 workbook
(Workbook)":

> conformance (Document Conformance Class)
> Specifies the conformance class ... to which the SpreadsheetML document conforms.
> If this attribute is omitted, its default value is transitional.

MS implementer notes tell [3]

> b. The standard specifies that the conformance attribute is a valid attribute of
> the workbook element.
> 
> Excel ignores the conformance attribute.
> 
> This note applies to the following products: Office 2010, Office 2010 Server,
> Office 2010 SP1.

... which is expected, since MSO 2010 and earlier presumably did not know (or
at least did not care at all) about that attribute.

So we *possibly* would want to specify the obsolete dateCompatibility attribute
(for completeness?), but need to realize that it will never help.

Also we need to explore why we don't export conformance at all *when saving to
"Office Open XML Spreadsheet"* (which is presumably our name for the
"strict"?). In that mode, as far as I see, dateCompatibility *is* exported
(with the expected zero significance).

[1]
https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oi29500/a251e7c6-7b8a-4e2f-b284-025f9f09ba3e
[2] https://www.iso.org/standard/71691.html
[3]
https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oi29500/7821b8f6-672a-4f05-bc0f-33b818210695

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210928/34f682e7/attachment-0001.htm>