>>>>>No problem and I don't care if you use or not. Woould you tell me what do you mean by "since this class returns an incorrect result"?
>>>>>Cetin
>>>>
>>>>

>>>>WITH CREATEOBJECT("age")
>>>>
>>>>	.CalcAge({^1988/2/29} ,  {^2006/09/21 })
>>>>
>>>>	CLEAR
>>>>	
>>>>	? .Years , .Months , .Days
>>>>	* CHECK with the correct definition Age = (((Birth+Y)+M)+D)
>>>>	?  GOMONTH(GOMONTH({^1988/2/29},.Years*12),.Months)+.Days
>>>>	* CHECK with a bad definition
>>>>	?  GOMONTH({^1988/2/29},.Years*12+.Months) + .Days
>>>>	?  gomonth(GOMONTH({^2006/09/21} - .Days, - .Months), - .Years *12)
>>>>ENDWITH

>>>
>>>18 years, 6 months and 22 days. Correct. I don't understand why you say it's a bad definition. Use pen and pencil.
>>>Cetin
>>
>>Cetin, try this. Do it with the above - {^1988/02/29}, {^2006/09/21}
>>18 years, 6 months, 22 days.
>>
>>Now try it with {^1988/03/01}, {^2006/09/21}
>>18 years, 6 months, 20 days
>>
>>It should only be 1 day less than the first attempt, not 2 days.
>
>The rule:
>

>birth + 1 then age + 1
>

>is not valid
>
>post these ages:
>

>{^1988/02/28}, {^2006/02/28}
>
>{^1988/02/29}, {^2006/02/28}
>
>{^1988/01/28}, {^1989/02/28}
>
>{^1988/01/29}, {^1989/02/28}
>
>{^1988/01/30}, {^1989/02/28}
>
>{^1988/01/31}, {^1989/02/28}
>
>

I think you meant Birth + 1 then age -1 is not valid.

I guess I have to agree, but it seems like it all comes down to not having a standard for age calculation.

If {^1988/01/28}, {^1989/02/28}
produces 1, 0, 0
And {^1988/01/29}, {^1989/02/28}
also produces 1, 0, 0
then what should {^1988/01/28}, {^1989/03/01} produce?
It gives 1, 0, 1 and that's not exactly right. Shouldn't it be 1, 0, 2?

Does it make sense then to only calculate age by number of days and forget about trying to figure years and especially months?