OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Excel 2007 != Ecma spec YEARFRAC. Not evenslightly. What should we do?

Ideally there'd be worldwide agreement.  But we need to decide what can be done if that will NOT happen soon.

>Maybe the solution is to have more than 5 bases?  We let 0-4 be the
>"Excel-compatible" options that match, as much as we can ascertain, what
>Excel 2007 does.  Then we have additional options 5, 6, 7, etc., that
>match current external financial authorities exactly.

I'd rather there be a bigger number gap for the different options.
We could define basis=128, 129, 130, and so on, and define both
Excel-2007-compatible algorithms and official algorithms.
If you use basis=128 in OpenDocument, then you'd be guaranteed to get
a particular algorithm.

That still doesn't resolve how to deal with basis=0 through 4.
If we can separate the algorithms from the basis mappings for 0..4,
we might be able to get the best of both worlds.  I.E., you could have a
recalculation setting that determined how basis 0..4 mapped.
Here's one approach: add a parameter called "basis_offset" to the sheet;
it's a value added to the basis value before YEARFRAC
and friends are called if the basis value < 128.
That would enable us to support many algorithm mappings, should
that prove to be necessary.
That's not ideal, but it's _an_ approach.  An advantage of this
approach is that we can handle legacy documents, which depended on
the Excel algorithms, as well as support standard basis values.
Other solutions welcome.

--- David A. Wheeler

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]