Date of Birth Validation Test Cases: Leap Years & Age

After we published names that break software, the natural question was which field to distrust next. The answer is the one that looks safest: date of birth. A birthday has a fixed format and only 366 possible month-day values. Yet it has frozen a whole line of music players, taken down a cloud platform, and quietly broken age calculations in systems that passed every normal test.

The difference is what software does with the field. A name is mostly stored and displayed. A birthday is calculated against: age, eligibility, cohorts, even the zodiac sign on a generated profile. Every one of those calculations replays the calendar's exceptions.

Why dates of birth are harder than they look

The calendar is an API with special cases baked in centuries ago. Months come in four lengths. One day exists only three years in four. The leap rule has an exception, and the exception has an exception. And there are competing ways to write a date down. A stored birthday touches all of them, again and again, for as long as the record lives.

The failures are also lopsided. Rejecting a valid date locks a real person out of a signup form. Accepting an invalid one plants a value that breaks later, in whatever job next does arithmetic on it.

The edge cases that actually break systems

29 February

About one birth in 1,461 lands on a leap day, so leap-day users are real. The rule behind their birthday is the one developers most often get half right. A year is a leap year if it divides by 4, except centuries, unless the century divides by 400. So 2000 was a leap year, 1900 was not, and 2100 will not be. A home-made divisible-by-4 check works perfectly for seventy-odd more years, then fails ^{[leap-year-wiki]}.

Even lawmakers have had to patch this case. In Hong Kong, Taiwan and the United Kingdom, a leap-day birthday counts as 1 March in common years. Hong Kong's ordinance says so outright, and Taiwan's civil code implies it. Contracts and coming-of-age rules need an answer for a birthday that does not exist three years in four ^{[leap-year-wiki]}. Your age code needs the same explicit decision, and a test that pins it.

The leap day's greatest hits are well documented ^{[leap-bug-wiki]}. On 31 December 2008, the 366th day of a leap year, Microsoft's Zune 30 players froze on start-up worldwide. The clock driver's loop subtracted 365 days at a time and had no branch for a remainder of exactly 366. It spun until the calendar rolled over at midnight.

On 28 February 2012, Pacific time, already 29 February in UTC, Windows Azure went down. Certificates were being issued with a validity of exactly one year, by changing the year without changing the day. 29 February 2012 plus one year is 29 February 2013, which does not exist. The failures spread into an outage that lasted most of a day. Neither bug was in date parsing. Both were in date arithmetic, the part that runs long after the form said everything was fine.

The year 1900, and Excel's deliberate bug

Spreadsheets are where birthday data gets mangled, and the best-known example is deliberate. Excel's 1900 date system treats 1900 as a leap year. Serial number 60 is 29 February 1900, a day that never happened. Microsoft documents this and kept it on purpose, for compatibility with Lotus 1-2-3, which made the same error first ^[excel-1900].

The effects on birthday data are real. Weekdays for early-1900 dates are wrong by a day. And the 1900 system cannot store any date before 1 January 1900. Paste a centenarian's 1899 birthday into a date column and it quietly becomes text, which then sorts and filters differently from every value around it. If your data passes through a spreadsheet anywhere, and someday it will, your fixtures should include the dates that expose this.

Ages that are off by one

The most common birthday bug never crashes anything. Subtracting the birth year from the current year overstates a person's age until their birthday, for up to 364 days. Where 13, 18, 21 or 65 unlocks something, that error grants or denies eligibility. Correct age math compares the full month and day. The boundary is exact: a person turns 18 on their birthday, not the day before or after. Only fixtures pinned to the boundary prove it: a birth date exactly 18 years before the reference date, and the same date one day later.

The second off-by-one comes from timezones. A date of birth is a calendar date, not a moment in time: nobody's birthday moves when they fly. But store it in a datetime column and it gains a hidden midnight, usually in UTC. Show that value in any timezone west of Greenwich and it becomes the previous day: born 10 May, shown 9 May. The fix is to keep birth dates as plain ISO 8601 dates, such as 1990-05-10, from end to end ^[iso8601]. A bug report titled 'my birthday is wrong by one day' almost always has this cause.

1 January, and other defaults that look like data

Plot the birthdays in any large real database and 1 January towers over every other date. Some of that is software. Epoch values like 1970-01-01, the zero of Unix time, leak out of code that confused 'unset' with 'the beginning of time' ^[unix-time]. But much of it is honest data.

When a person's real date of birth is unknown, officials have long written 1 January. That is common in refugee and immigration paperwork from places where births go unregistered. Of the nearly 80,000 refugees admitted to the United States in 2009, about 11,000 had a 1 January birthday on file ^[npr-jan1]. The lesson cuts both ways. A pile of 1 January birthdays is not proof of corruption. And a matching system that treats 'same date of birth' as strong evidence will merge thousands of different people who share only a clerk's habit.

Two-digit years and ambiguous formats

The Year 2000 problem was, at heart, a date-of-birth problem. Two-digit years forced every system to guess the century. Rules that read '25' as 1925 or 2025, depending on a cut-off year, filed centenarians as newborns and the reverse ^[y2k-wiki]. Two-digit years are mostly gone from storage. They survive in date pickers, CSV exports and scanned paper forms.

Their cousin, format ambiguity, is fully alive: 03/04/2001 is 4 March in New York and 3 April in London. Writing dates in ISO 8601 removes the question ^[iso8601], but only in systems you control. So test data should include dates with a day above 12, because only those cannot be swapped silently. The next epoch is already scheduled. 32-bit Unix timestamps overflow on 19 January 2038, which is closer to today than the Y2K clean-up is behind us ^[unix-time].

A birthday fixture set worth copying

Run every fixture through the whole life of a record, not just the form. Create it, show it in at least two timezones, calculate the age on both sides of the birthday, and export and re-import it in every format you support. The 29 February and 1899 rows fail most often in the export round trip. The boundary rows fail most often in a batch job someone wrote years after the form.

How our generator handles birthdays — including two bugs we shipped

Every profile from our identity generator has a birthday, an age and a zodiac sign, and generation is deterministic from a seed. The engine picks a target age between 18 and 80 and a month and day anywhere in the calendar. It then works out the birth year that makes the age exact on a fixed reference date. There is no clock read, so the same seed always produces the same person. In a check of 10,000 profiles on 1 October 2026, every age matched its birthday.

One result is deliberate: the engine never produces 29 February. The leap day exists only in leap years, so allowing it would tie those birth years to leap years and skew the age spread. A random generator would hit it only once in about 1,461 draws anyway, which makes it a poor way to test that path. For leap-day coverage, take the fixtures from the table above. Random data is the wrong tool for a boundary you can name.

We write this with some humility, because we shipped two of these bugs ourselves. Our first version picked the year first. It then limited the month and day to fall on or before the reference date. The default reference date was 1 January, so the 'anywhere in the calendar' draw collapsed to one value. For a while, every identity this site generated without an explicit reference date was born on 1 January. All of them were Capricorns.

The same routine also capped every month at 28 days, so nobody was ever born on the 29th, 30th or 31st. Both bugs produced flawless individual records: every date valid, every age exact. That is exactly why row-by-row validation never flagged them. Today's engine spreads birthdays across all 365 month-days, with 1 January at its expected share of about one in 365.

The conclusion matches the one we reached about names: validate less, test more. Reject the dates that cannot exist. Accept everything that can, including the leap day, the centenarian and the person who turns 18 today. Spend the effort you save on fixtures that walk the boundaries, and on totals that catch what row checks never will. For the fields next to this one, read names that break software and phone numbers that break software. For a thousand consistent profiles to run your own histograms on, the generator is free and reproducible from a seed.