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] EOMONTH Function Test Cases (Section 6.9.8)


Hi Andreas,

On Sunday, 2009-02-22 11:59:04 -0700, Andreas J. Guelzow wrote:

> EOMonth takes a DateParam, so in the suggested function call implicit
> conversion is involved.
> 
> I guess I misread 6.2.11. The "implementation defined" there appears
> only to apply to the second clause.
> 
> But using the first clause, and checking the definition of DateValue I
> still don't see any requirement that the serial number (which I take to
> be equivalent to DateParam) for returned by DateValue for  "2006-01-05"
> must be the serial number for a day in January. The definition only
> requires DateValue to _accept_ any  YYYY-MM-DD. It does _not_ say that
> is must be the same serial number as DATE(YYYY,MM,DD). 

Do we need to explicitly state that? To me it is obvious that when
requiring to accept an ISO date string the Date value returned has to be
the corresponding date serial, not any other value. Everything else just
doesn't make sense. Anyway, we can say that the result of
DATEVALUE("YYYY-MM-DD") must be the date serial equal to
DATE(YYYY;MM;DD)

> > The form YYYY-MM-DD is intended to be completely unambiguous; that 
> > format is _ALWAYS_ ISO format.
> 
> I agree that that is desirable but I don't think it is curently
> required. SO rather than using implicit conversion and "2006-01-05"
> shouldn't hose examples use DATE(...)?
> 
> >   Yes, we have the problem that MM/DD/YY 
> > and DD/MM/YY are both in use, but that's not the format in view here. 
> > ISO format was used for in the test cases specifically because it's NOT 
> > ambiguous.
> 
> Since you want to test EOMONTH you really shouldn't use implicit
> conversion which tests also DateValue. DATE seems to be more reasonable
> since less controversial. 

Seconded. The conversion should be tested only for DATEVALUE.

> If you read the definition of DATEValue, it doesn't really say what the
> return value should be only what it should "accept".

Would this

    The date serial number returned for DATEVALUE("YYYY-MM-DD") is the
    same as the date serial number returned for DATE(YYYY;MM;DD).

do fine?

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.

PGP signature



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