Re: [office-formula] EOMONTH Function Test Cases (Section 6.9.8)

[Andreas J Guelzow <aguelzow@math.concordia.ab.ca>]

On Sun, 2009-02-22 at 07:41 -0500, David A. Wheeler wrote:
> Andreas J Guelzow wrote:
> > how could this be? According to the draft, the conversion of
> > "2006-01-05" into a date is implementation defined, so that date could
> > be May 1st!
> 
> Where do you see that?  If it says that, it's a mistake.

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

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

Andreas
> 


-- 
Andreas J. Guelzow
Concordia University College of Alberta