G
Guest
I use a query, designed by someone else, that pulls the hire date for
employees from the database, and then performs a calculation on it to get the
number of years worked. It uses DateDiff to get the number of days between
now and the hire date, and then divides that value by 365.25.
Obviously, this is not good enough. Using this method, if it tries to
calculate the years elapsed between July 1, 1996 and July 1, 2005, it gives
this result:
8.9993155373032169746748802190281 years
But the result should be exactly 9 years.
I want it to calculate the number of CALENDAR years, not, y'know,
"astronomical years" (or whatever the term is for the time it takes the earth
to make one orbit around the sun). Calendar years are not all the same
length. This should be taken into account in the calculation.
Thus, the years from July 5, 2001 to June 3, 2004, should be 2 333/366,
which is in decimal:
2.9098360655737704918032786885246
But the years from July 5, 2000 to June 3, 2003 should be 2 332/365, which
is in decimal:
2.909589041095890410958904109589
I figure this kind of calculation is a bit too complex to all fit in the
field of the query. Probably it needs a macro. Does one like this perhaps
already exist? Or can someone point me in the right direction for writing it
myself?
employees from the database, and then performs a calculation on it to get the
number of years worked. It uses DateDiff to get the number of days between
now and the hire date, and then divides that value by 365.25.
Obviously, this is not good enough. Using this method, if it tries to
calculate the years elapsed between July 1, 1996 and July 1, 2005, it gives
this result:
8.9993155373032169746748802190281 years
But the result should be exactly 9 years.
I want it to calculate the number of CALENDAR years, not, y'know,
"astronomical years" (or whatever the term is for the time it takes the earth
to make one orbit around the sun). Calendar years are not all the same
length. This should be taken into account in the calculation.
Thus, the years from July 5, 2001 to June 3, 2004, should be 2 333/366,
which is in decimal:
2.9098360655737704918032786885246
But the years from July 5, 2000 to June 3, 2003 should be 2 332/365, which
is in decimal:
2.909589041095890410958904109589
I figure this kind of calculation is a bit too complex to all fit in the
field of the query. Probably it needs a macro. Does one like this perhaps
already exist? Or can someone point me in the right direction for writing it
myself?