Quick answer
Store the date of birth, the reference date and the result together. An age without its date cannot be verified and quietly becomes wrong.
The value that decays silently
Most incorrect data announces itself eventually — a broken link fails, a missing field errors. An age does neither. It sits in a file looking exactly as valid as the day it was written, becoming steadily wronger at a rate of one year per year.
This is why an undated age is worse than no age at all in a record that will be read later. A reader with no age asks; a reader with a stale age proceeds.
Use this guide with the right tool: Open the Age on a Date Calculator for chronological age on a past or future date. If the question shifts, compare it with the Chronological Age Calculator or the Age Calculator.
What a verifiable record contains
Three fields at minimum: the date of birth, the reference date, and the result. With those, anyone can reproduce the calculation and detect a mistake. Without the reference date, they can only recalculate to today and get a different answer with no way to tell whether the original was wrong or simply old.
For anything where a convention was applied — a rounding rule, a Y;M;D format, a corrected age — add a fourth field naming it. That is the difference between a record someone can audit and one they have to take on trust.
Why the reference date is a decision
The reference date is not merely a timestamp; it is a statement about which day the age is meant to describe. For an assessment it is the administration date. For an eligibility check it is the cutoff. For an incident it is the incident date. Each of those is a deliberate choice with consequences.
Recording it therefore captures reasoning, not just metadata. A reviewer who can see that the age was calculated to the assessment date rather than the report date knows the right thing was done, without having to ask.
Systems, not discipline
The reliable fix is structural. Store the two dates as date fields and derive the displayed age, so the display cannot go stale. Where a snapshot must be stored — because it fed a decision at a point in time — store it with its date and treat it as a historical record rather than a current value.
Where you are working outside a system, the shareable result link is a serviceable substitute: it encodes both inputs in the URL, so the calculation reopens rather than needing reconstruction.
Worked example
The shape of the calculation stays the same with your own figures. What changes is the source of the rule, so check that before treating the number as settled.
Common mistakes to avoid
- Storing a computed age as a current value. Store the dates and derive the age, or the display goes stale with no warning.
- Omitting the reference date from a report. The age cannot be verified, and a reviewer has no way to distinguish an error from a stale figure.
- Leaving the convention unstated. If a rounding or format rule was applied, name it. Otherwise the number cannot be reproduced exactly.
Use the right calculator
Start with whichever matches the information you already hold. The other two are there for when the question shifts.
Frequently asked questions
Is the calculation date the same as the reference date?
Not necessarily. The reference date is the day the age describes; you might calculate it weeks later. Record the reference date.
How long does a recorded age stay usable?
Until the next birthday, at most, and less if months and days matter. Treat any undated age as unusable.
What is the minimum to record?
Date of birth, reference date, result. Add the convention if one was applied.