As usual with age, leap year birthdays are the deciding factor.
If someone was born on Feb 29, 2004, how old are they on Feb 28, 2018? In your code, 13. But in some jurisdictions, legally that person is 14 on Feb 28. In other jurisdictions, you can use Mar-1 as their birthday in non-leap years.
Edit: Btw, get rid of the variable in the function, it adds slight overhead unnecessarily:
Hi Scott,
Thanks for your comments!
My function gets the correct age, but I agree, there will always be one-off business rules to be applied. In your leap-year example, the age would not be augmented, instead, the rule would be applied outside the function. For example, a jurisdiction such as you mentioned would not alter a subjects age, but they might allow the subject to buy beer at 20 if non-leap year, and date is Feb 28, and subject DOB is Feb 29. Heck, I could pass a law that grants you the grandpa discount if your dog has pups, but that wouldn't actually make you a grandpa - and your subject is still 20 on Feb 28.
I agree, the variable is not needed. More of a style issue where I normally use vars to standardize return values across functions. You might be surprised, but benchmarks won't improve measurably by removing this var. Note, this is not interpreted code.
Yeah, it's interesting how complicated this "simple" age thing can be!
But, no, the age is 21, you cannot buy beer at 20, that is illegal. Nor get your pension at an earlier age (there could be a significant dollar difference here). You must give the person the correct age, not just pretend they are a different age for one day for whatever reason.
As to unnecessary local variables, I'm not going to waste resources on it, particularly since it's the only local variable used. I've found extraordinarily few scalar functions that actually need a local variable to store the return value.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.