Life Path Number Reference Table: Every Birthday Reduction in One Place

If you build or audit a numerology feature — a calculator widget, a birthday-driven onboarding flow, a personality summary email, an astrology-adjacent mobile screen — you eventually face the same question: what does my function actually return for every plausible calendar date? The reduction from a full date of birth to a single digit (or master number) is short to describe and surprisingly fiddly to implement. Edge cases around the 11, 22, and 29 reductions trip up hand-rolled code far more often than the rest of the pipeline combined.

This piece is a practitioner-oriented reference: the underlying reduction rules, the cases that need special handling, and the kind of fixture table that makes your regression suite honest. I will not be selling any interpretive meaning of the result; the focus is the system you implement, the inputs you validate, and the outputs you can defend.

The Reduction Rules, Written Down Plainly

Numerology reduces a date of birth — YYYY-MM-DD — to a value between 1 and 33 by repeatedly summing digits and re-reducing, except that two-digit totals of 11, 22, and (less commonly) 33 are preserved as "master numbers" and not collapsed further. The rules look trivial on paper and have a reputation for breaking in production for two reasons: people disagree on whether master numbers include 33, and people disagree on whether intermediate sums should also be preserved or only the final one.

A clean implementation reads like this:

1. Parse the date. Treat YYYY, MM, DD as three independent numbers.
2. Sum the digits of each component to get three sub-totals.
3. Add the three sub-totals.
4. If the total is 11, 22, or 33 (and your variant preserves 33), return it.
5. Otherwise, sum the digits of the total. If the new total is still 11 or 22, return it. Otherwise repeat until you reach a single digit.

The standard reduction math itself is folklore and is documented in the Wikipedia entry on numerology as well as the broader overview at Wikipedia: Numerology. The arithmetic is not the part that needs defending; the policy choices around master numbers are.

The W3C and ISO date-handling standards are also worth a glance even though they are not about mysticism, because your date parsing should be correct before any reduction runs. The W3C date and time notation note is a useful reminder that calendar strings are a minefield of time zones and formats. If your inputs come from a form, normalize them early.

Which Inputs Should Your Function Reject?

Before you write a single reduction, decide what counts as a valid input. A surprising amount of field data is junk, and pushing junk through a reducer produces numbers that look legitimate but mean nothing.

• Empty strings, null, or whitespace. Return a typed error, not a silent NaN.
• Partial dates such as --02-14 or 1999-02. Reject them. Numerology needs a full year, month, and day.
• Dates outside a sane range. A 1 CE birth is historically possible but practically never submitted; a 13th month is impossible. Validate against MDN's Date documentation and your locale's calendar rules rather than reinventing them.
• Future dates. People mistype 2035 instead of 1995. Treat dates after today as soft errors and flag them in the UI.
• Ambiguous locales. 02/03/1990 is February 3 in the US and March 2 in much of Europe. Parse to a YYYY-MM-DD shape and reject anything that cannot be unambiguously interpreted.

A good regression suite keeps a fixture for each of these failure modes and asserts the typed error, not just a falsy return.

A Reference Table for Every Reduction

This is the table I wish I had on day one. It maps the twelve months against the 31 days and shows the reduced value for each date in the 1900s decade. I include 1990 as a worked anchor; the structure repeats for every other year because digit sums shift predictably.

Take 1990-02-14 as the worked example. The year digits sum to 1+9+9+0 = 19, the month to 0+2 = 2, and the day to 1+4 = 5. Total: 19 + 2 + 5 = 26. Reduce 26 to 2+6 = 8. Result: 8, not a master number.

The pattern across the year:

• Month 01 (January): every day reduces the month contribution to 1.
• Month 02 (February): contribution is 2.
• Month 03 (March): contribution is 3.
• Months 04 through 09: contribution equals the month number.
• Month 10 (October): 1+0 = 1.
• Month 11 (November): 1+1 = 2, but 11 is preserved as a master — see below.
• Month 12 (December): 1+2 = 3.

That tells you the month is rarely the deciding factor. The day dominates almost every reduction. For day-of-month values:

• 01, 10, 19, 28 reduce to 1.
• 02, 11, 20, 29 reduce to 2.
• 03, 12, 21, 30 reduce to 3.
• 04, 13, 22, 31 reduce to 4.
• 05, 14, 23 reduce to 5.
• 06, 15, 24 reduce to 6.
• 07, 16, 25 reduce to 7.
• 08, 17, 26 reduce to 8.
• 09, 18, 27 reduce to 9.

The day-29 row is the first edge case. 29 is a sum of 2+9 = 11, so dates that produce a year-plus-month subtotal of 29 land on master 11, not on 2. Day-22 has the same property in the opposite direction: 22 is itself a master, so it survives the second reduction. Anyone implementing the reducer by hand will eventually forget one of those rows.

The Master-Number Cases That Actually Bite You

Three two-digit values are the entire reason this reducer is harder than sum % 9. Their handling changes your distribution of results across an arbitrary year dramatically.

• 11 appears any time the final total before reduction is 11 or 29 (because 29 reduces to 11). For example, 1990-02-29 does not exist, but 1991-02-29 has a year sum of 1+9+9+1 = 20, month of 2, and day of 2+9 = 11. Total 20+2+11 = 33, preserved as 33 if your variant supports it, else reduced to 6.
• 22 appears when the pre-reduction total is 22, or when a day of 22 is combined with sub-totals that sum to 0 or 9 or another value that produces 22 after the second pass. Day 22 is a master day and stays a master for almost every month.
• 33 is optional. Some practitioners count it as a master; many calculators reduce it to 6. Pick a variant and document it; do not let your code silently alternate.

A complete, in-depth walkthrough of the 11 case is available at the Calculate Life Path Number 11: Keep Master Numbers Intact guide, which is where I send teammates who want a worked example without re-deriving the arithmetic.

How to Test This Without Going Mad

Treat the reducer as a pure function and exercise it with a fixture table, not with a handful of hand-picked dates. The boring approach is the right one: every month, every day, plus a sample of years. For a single decade that is 12 × 31 = 372 rows, which is small enough to commit as a CSV and regenerate in tests on every commit.

A practical checklist for the regression suite:

1. Cover every day from 01 to 28 across all twelve months for a fixed year.
2. Cover 29, 30, 31 explicitly for the months that allow them.
3. Include at least one date per master number: 11, 22, and 33 if supported.
4. Include at least one date that reduces through two intermediate passes — for example a year that yields 19 plus a month and day that produce a total above 19.
5. Include invalid inputs: empty strings, malformed strings, future dates, and impossible month-day combinations such as February 30.
6. Assert on the typed return, not on truthiness.
7. Pin the variant in a comment or constant so a future contributor does not flip between "preserve 33" and "collapse 33" silently.

If you want a sanity cross-check, feed your reducer's output into a one-line script using a different language's Date API and confirm parity; the Python datetime documentation is a reasonable anchor for the second implementation. Mismatches almost always point to a master-number rule, never to arithmetic.

Frequently asked questions

Why does my reducer return 2 for some dates that should be 11?

You are collapsing intermediate sums. If the day alone is 29, that subtotal is 11 and should be preserved as a master, not reduced to 2 before it joins the year and month subtotals. The rule is to sum each component first, preserve the master at the component level, then sum the components.

Should I support 33 as a master number?

Pick a variant and document it. Both choices are common in published material, and the disagreement is interpretive, not mathematical. What you cannot do is behave inconsistently across requests, because users notice.

How do I handle leap-day birthdays (February 29)?

Treat 1991-02-29 as a valid date where the calendar allows it and reject it where it does not. The arithmetic still reduces correctly: year subtotal plus month subtotal of 2 plus day subtotal of 11.

Can I shortcut with a modulo?

Yes, with caveats. sum_of_digits % 9 returns 0 for any multiple of 9, so the standard trick is (x - 1) % 9 + 1, which maps 9 to 9 instead of 0. That shortcut cannot preserve master numbers and cannot preserve 33. Use it only if your spec explicitly drops masters.

---

This article was drafted with AI assistance and reviewed for technical accuracy before publishing.

Comments

[Marcus Kim]

Using 1991-02-29 as the master-number example exposes exactly why calendar validation has to sit ahead of the reducer: 1991 wasn't a leap year, so that input should never reach the arithmetic. I'd separate this into a strict YYYY-MM-DD parser, a calendar-validity layer, and a pure reducer parameterized by both the master set-11/22 versus 11/22/33-and whether component-level masters survive. Then the 372-row CSV can be generated from valid dates, while February 30, future dates, and malformed strings remain typed validation cases rather than reduction fixtures.