Re: [office-formula] DAYS360

On Fri, 2010-11-05 at 14:19 -0600,  wrote:
> "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,

in Excel 2007:
=DAYS360(DATE(2000,2,28),DATE(2000,3,31),0) is 33 but
=DAYS360(DATE(2000,2,29),DATE(2000,3,31),0) is 30 and
=DAYS360(DATE(1999,2,28),DATE(1999,3,31),0) is 30

so clearly there are leap year considerations here.

Andreas