"Andreas J. Guelzow" <> wrote on 11/05/2010
03:20:54 PM:
> Subject:
>
> Re: [office-formula] DAYS360
>
> On Fri, 2010-11-05 at 13:04 -0600, Patrick Durusau wrote:
> > Greetings!
> >
> > We forgot to update DAYS360 when Rob did YEARFRAC.
> >
> > It still talks about US/NASD and European Method, which we know give
> > different results.
> >
> > I am moving on to enter other edits but wanted to point this out as an
> > issue.
> >
> > Suggestion: Should I simply make 0 = Procedure A and 1 = Procedure D?
> >
> > We say that DAYS360 varies from Procedure A. Is that because dates are
> > never swapped or some other reason?
>
> The Gnumeric documentation says:
> Note: If method is 0, the default, the MS Excel (tm) US method will be
> used. This is a somewhat complicated industry standard method where the
> last day of February is considered to be the 30th day of the month, but
> only for start_date.
>
> Note: If method is 1, the European method will be used. In this case,
> if the day of the month is 31 it will be considered as 30.
>
> I am not sure of course whether this is consistent across implementation
> but Gnumeric ought to match Excel in this case.
>
The Excel definition is here:
http://office.microsoft.com/en-us/excel-help/days360-HP005209047.aspx
It looks like the dates are not swapped. It can return a negative number.
Since it doesn't involve year-length calculations, like YEARFRAC() does,
we should not need to worry about leap year complexities. But I cannot
guarantee that there are no "quirks" like we saw in YEARFRAC().
-Rob
