[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] DAYS360
"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]