🎂 CakeAlert
← All articles

Why Every Calendar App Still Gets February 29 Birthdays Wrong

September 14, 2026 · The CakeAlert team

Roughly one person in 1,461 is born on February 29. For three years out of every four, that date simply doesn’t exist on the calendar — and it turns out an enormous amount of software, from calendar apps to enterprise marketing platforms to security tools, never actually decided what to do about that. Not “decided wrong.” Decided nothing, and found out when a leapling’s birthday quietly broke something.

This isn’t a rare edge case nobody hits — it’s a rare edge case everyone’s software already hit

The Honor Society of Leap Year Day Babies — a real advocacy group for people born on Feb 29 — keeps a running list of exactly this happening, in public, to real companies. Microsoft’s own security software “failed to accommodate Leap Day” in 2012. Google’s Blogger platform rejected February 29 as an invalid date outright. A toy store chain’s birthday club denies leaplings their birthday perk “in three years out of four,” because its system only checks for a date that isn’t there. CafePress calendars print every other date of the year and leave February 29 blank.

It’s not just consumer software. Salesforce Marketing Cloud — an enterprise platform companies pay real money for — doesn’t automatically catch Feb 29 birthdays in date-triggered campaigns at all. DESelect’s own guide for SFMC users has to walk marketers through writing custom SQL with a leap-year modulus check just to make sure those customers get their birthday offer on some day in a common year, because the platform won’t do it on its own. And Google’s own Calendar Help Community has a user-reported thread titled, plainly, “Leap day birthday (Feb 29) is being shifted to Feb 28 instead of March 1 in non-leap years” — a real complaint, on Google’s own product, about which date its recurring events pick.

There’s no universal right answer, which is exactly the problem

Here’s the part that makes this genuinely harder than a normal bug fix: there isn’t one correct substitute date to fall back to. Legal codes don’t even agree. Taiwan’s civil code and Hong Kong’s law both fix a leapling’s birthday as March 1 in common years; the UK treats it the same way. Other jurisdictions and institutions land on February 28 instead. Wikipedia’s own summary of the leap year article documents both conventions existing side by side, with no single standard uniting them — which is a real problem for building software.

That ambiguity is exactly why so much software just… doesn’t handle it. Throwing an error, rejecting the date at signup, or silently skipping the year is the path of least resistance when there’s no consensus answer to fall back to. For a birthday reminder specifically, that path of least resistance means the worst possible outcome: a leapling sets up their reminder once, it works the one year in four the date actually exists, and then it either breaks or simply never fires again for the other three — with nothing telling them why.

What a reminder actually owes a Feb 29 birthday

Not a philosophical stance on which convention is “right” — there isn’t one. What it owes is a fallback that’s deterministic and never breaks. CakeAlert’s recurrence logic does exactly that: a Feb 29 celebration resolves to February 28 in every non-leap year, every time, by design — not a crash, not a skipped year, not a silent no-op. It’s a small piece of code with a comment that says exactly what it’s for, because getting this right takes deciding to handle it at all, which is the one thing leapyearday.com’s whole list of examples has in common: nobody decided.

Create a free CakeAlert account — no card needed — and give the birthday that keeps breaking other people’s software a reminder that just quietly works, leap year or not.

Never forget another birthday.

Import your birthdays once — CakeAlert handles the rest.

Create my free account