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] 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:


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().


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