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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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


Subject: Re: [office-formula] Groups - basis-test.ods uploaded


"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 09/27/2010 
11:42:03 PM:

> 
> Re: [office-formula] Groups - basis-test.ods uploaded
> 
> Running this through Gnumeric I see 2 FALSE: G10 and G11 
> Something not-tested but suspicious in Gnumeric is
> =yearfrac(date(2010,2,28),date(2010,2,28),0) results in non-zero.
> 
> These could be bugs in Gnuemric but OOo has also G10 and G11 as FALSE.
> (OOo also has several FALSE for basis 1.)
> 
> I don't have Excel to try...
> 
> Andreas
> 

G10 and G11 are both tests of Procedure A, step 6:

6.  If both date1 and date2 are the last day of February, change both 
dates to the 30th of the month.

Excel appears to follow this rule, at least when I test it with Excel 
2003.

And remember, we don't have many great choices on how we define these 
functions.  Ideally we'd use some authoritative reference to define these 
calculations.  But I have been unable to come up with any.  The official 
references are vague on the precise details, especially around leap year 
treatment.

So our options are:

1) Use official, but vague definitions and leave the details to be 
"implementation-defined"

2) Define the precise behavior on our own, based on what seems logical and 
consistent to us, regardless of what implementations do.

3) Define different date basis values to match each implementation's 
existing calculations.  "Everyone wins...except the user"

4) Mimic what Excel does.

I don't love any of these choices, but the work to date on the financial 
calculations has been aligned with goal #4. 

-Rob



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