Quick answer
Read 8;06;04 as eight completed years, six completed months and four days. Never treat the separators as decimal points, and follow the manual's padding convention.
Three fields, not one number
The semicolon format exists because chronological age is three separate counts, not a single quantity. Years, months and days each roll over on their own schedule, and none of them converts cleanly into the others. Writing them as distinct fields keeps that structure visible.
The most consequential misreading is treating the format as decimal. 8;06;04 is not 8.64 years and not 8.06 years — it is eight years, six months and four days, which is roughly 8.51 in decimal terms. A record that has been silently decimalised is very hard to detect later, because the number still looks plausible.
Use this guide with the right tool: Open the Chronological Age Calculator for chronological age on an assessment date. If the question shifts, compare it with the Pearson Age Calculator or the Assessment Age Calculator.
Padding conventions differ
Some manuals require two digits in the months and days fields, giving 8;06;04. Others accept 8;6;4. A few use a hyphen or a colon instead of a semicolon. None of these is more correct in general; what matters is matching the instrument you are scoring against, because the scoring table is indexed that way.
Where you control the record — a case file, a spreadsheet, an internal template — pick one convention and hold it. Mixed padding within a single dataset is a reliable source of sorting errors and of values that fail a later import.
What the days field means
The days field is the remainder after complete months have been counted, so it ranges from 0 to 30 depending on the length of the boundary month. It is not a thirtieth of a month, and it does not represent a fixed fraction.
This is why the borrow step in manual calculation produces so many errors. Borrowing a flat thirty days when the boundary month has 28 or 31 gives a days field that is off by up to three, which is enough to matter near a band boundary. Calendar-aware arithmetic uses the real length of the month being borrowed from.
Storing it so it stays usable
A Y;M;D value alone is not reproducible. Store it with the date of birth, the reference date and the name of the instrument or purpose it was calculated for. Those four together let any reviewer recreate the number without asking you.
For anything that will be sorted, filtered or analysed later, store the two source dates as proper date fields and derive the Y;M;D string for display. A text field holding "8;06;04" sorts alphabetically, which puts 10;00;00 before 8;06;04 and will eventually cause a problem.
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
- Reading the separators as decimal points. Y;M;D is three counts, not one number. The decimal equivalent is materially different and the error is invisible once copied.
- Swapping the months and days fields. 8;04;06 and 8;06;04 are two months apart. Confirm field order against the manual before transcribing.
- Borrowing a flat thirty days. Borrow the real length of the boundary month, or the days field can be wrong by up to three.
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 Y;M;D a standard?
Not a formal one. It is a widely used convention in assessment practice, with padding and separator details varying by publisher.
How do I convert Y;M;D to a decimal age?
Calculate the decimal separately from the two source dates rather than converting the string. Converting introduces an approximation the original did not have.
Should the days field ever exceed 30?
No. Once it reaches the length of the boundary month it becomes another complete month. A value of 31 or more indicates a calculation error.