RE: [office-comment] DAYS360 third parameter should be Logical

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

My concern about the Gnumeric extension is that it makes a breaking change, whereas the change between (0, non-zero) and logical does not, since implementations are permitted to cast on that basis, and the current OpenOffice.org-based implementations do that already, whether it was a good idea or not.

The risk, of course is that down-level implementations will interpret the added value incorrectly and also won't preserve it.

The users we hear from are concerned about interoperability and not mystery differences.  The benchmark for most of those interoperability concerns is Excel (usually .xls[x], althopugh the same limitations apply for .ods interchange with Excel).  

Secondarily, interoperability between Apache OpenOffice and LibreOffice as the most prominent implementations of ODF also matters, and that will extend to how implementation-defined/-dependent cases too since our end-users are not standards-police.

 - Dennis

> -----Original Message-----
> From: Andreas J. Guelzow [mailto:andreas.guelzow@concordia.ab.ca]
> Sent: Thursday, June 30, 2016 10:11
> To: office-comment@lists.oasis-open.org
> Subject: Re: [office-comment] DAYS360 third parameter should be Logical
> 
> Hi,
> 
> on behalf of Gnumeric I object to this change. Moving the last argument
> from an integetr (0,1) to a logical would prevent extending this
> function to further methods. Currently Gnumeric allows 3 methods
> (0,1,2), although it is clear that the behaviour for 2 is not as
> described in teh standard.
> 
[ ... ]
> On 16-06-30 10:21 AM, Dennis E. Hamilton wrote:
> >
> >> -----Original Message-----
> >> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> >> Sent: Friday, May 27, 2016 10:20
> >> To: office-comment@lists.oasis-open.org
> >> Subject: RE: [office-comment] DAYS360 third parameter should be
> Logical
> >>
> >> I provided the following cases in an OpenDocument Spreadsheet (.ods)
> >> file and obtained these results in all of Apache OpenOffice 4.1.2,
> >> LibreOffice 5.0.0, and Microsoft Excel 2016:
> >>
> >>   	330 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31))
> >> 	330 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31);0)
> >> 	330 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31);FALSE())
> >> 	332 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31);1)
> >> 	332 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31);TRUE())
> >> 	332 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31);2)
> >> 	332 =DAYS360(DATE(2015; 2; 28); DATE(2016;1;31);-20)
> >>
> >> The proposal to change the optional parameter to Logical with default
> of
> >> FALSE() will not impact interoperability so long as the rule for
> >> conversion of NUMBER to LOGICAL is retained in the specification.
> >>
> >> This change should not impact existing OpenDocument Spreadsheet
> >> instances or ODF down-version implementations of DAYS360.  It also
> >> prevents a future breaking change where values different than 0 and 1
> >> are given special interpretation.
> >>
> >> I personally see nothing objectionable in Eike's proposal.  I have
> not
> >> consulted the Apache OpenOffice Project.  I will do so by forwarding
> of
> >> this comment.
> >>
> >>   - Dennis
> > [orcmid]
> >
> > There have been no objections on this on the Apache OpenOffice lists.
> >
> >   - Dennis
[ ... ]