Calculating Age

[Lewy]

Last year I posted the question on how to calculate a person's age in a report using the function Year() and the persons Date of Birth, and following experts answers I have been using the following expression in a calculated field:
year(today())-year([MASTER.DoB])

However since the New Year this has been giving an incorrect age, making people a year older than they actually are, not good if your client is female!!(grin)

Any suggestions on how to get around this little problem.

Also is it worth upgrading from Paradox 7 to either 9 or 10, what benefits will I gain?

Many thanks in anticipation of some help.

Lewy

 

[JoeNg]

Pdox 7 is not Y2K.
You must stored the year in 4 digits, 2001 not 01, in your table.
Plus, you may have to modify your codes to handle Y2K.
For example;
If you see 01 to 20, convert it into 2001,2020 etc.

If Pdox works for you now, I see no reason to upgrade.

 

[ros]

This isn't a Y2K issue. when you subtract the years, you get what age a person will be on their birthday in the current year.
instead of
year(today())-year([master.dob])
try
int(longint(today()-[DATES.Date1])/365.25)

This takes the number of total days and divides by the number of days per year. Its fairly accurate except may round down around someones birthday.

HTH,
ros
ps. Paradox 7 is Y2K compliant, however current century is assumed so you just have to ensure 4 digit year entry for 19.. dates. 1/1/80 = 1/1/2080 NOT 1/1/1980

 

[JoeNg]

I don't know about Pdox 32-bit version, but Pdox 7 16-bit version is not Y2K compliant. I am pretty sure none of the Pdox 7 versions are Y2K compliant. That is, if you enter 02 as year, Podx treat it as 1902, not 2002. I spent a good part of 1999 updating all my applications. All date values in tables have 4-digit year. Codes are also changed to treat all inputed years between 00 to 20 as 2000 to 2020. I hope by then I'll have a new work or retired with my all dot-com stocks, not!

run this in Pdox 7 16-bits
Example 1:
MsgInfo("",int(longint(today()-DateVal("01/01/61&quot)/365.25))
Result: -58

Example 2:
MsgInfo("",year(today())-year(DateVal("01/01/61&quot))
Result: -59

Example 3:
MsgInfo("",int(longint(today()-DateVal("01/01/1961&quot)/365.25))

Example 4:
Result: 41
MsgInfo("",year(today())-year(DateVal("01/01/1961&quot))
Result: 41

As you can see from Example 3 & 4, if you put in the right year, they both yield the same result.

 

[ros]

>>That is, if you enter 02 as year, Podx treat it as 1902, not 2002.
This is not the case in paradox 32bit.

Your examples disprove your point not prove it.
if you enter 1/1/61 paradox treats it as 1/1/2061, CURRENT century as I stated. The calculation is correct
2002 - 2061 DOES EQUAL -59

Paradox stores dates internally as longints. There is no Y2K problem as long as the user understands that two digit years are CURRENT century. Put a date in a table as 1/1/61. Close paradox and change the date in windows to sometime in 1999. Then open the table and see that the date is 2061. The default behaviour is to show current century dates as two digit years and otherwise 4 digit. This is different to many other products which do &quot;windowing&quot; (ie. > 50 = 19.. <50 = 20..) but it is not a Y2K bug.

>As you can see from Example 3 & 4, if you put in the right >year, they both yield the same result.

You are being misled by the example date you used. The result is correct only because the birthday 1/1 has passed.
If you used 2/1/1961 then you would still get 41 with example 4 which would be wrong. You would get 40 with example 3 which is correct. The algorithm in example 4 is incorrect. This is not a paradox or Y2K issue. This would happen in any language.

ros

 

[ros]

Another date to try is 12/31/2001. Year subraction will give an age of 1 to a newborn less than 2 weeks old. Correct age of 0 will be given by the suggested algorithm.

ros

 

[JoeNg]

D'oh! You are correct. I should check my math.