Figure Out How Many Days Are In Any Given Year
You start by checking whether the year is divisible by 4. That is the basic rule that most people remember. If it divides evenly, you normally add an extra day. But there is a second filter that catches most of the mistakes I see people make online. Years divisible by 100 are not leap years unless they are also divisible by 400. So 1900 was not a leap year, but 2000 was. The Gregorian calendar settles on 366 days for leap years and 365 for everything else, with that exception baked right in. I used to handle scheduling logic for a logistics company where we calculated delivery windows across multiple years. One year, a junior dev wrote a function that simply checked divisibility by 4 and called it a day. The system started miscounting for dates past February 29th in years like 1900 and 2100. We had three months of shipping manifests with wrong day counts before someone actually traced it back. The workaround was straightforward once we found it: add the century check to the logic. The corrected condition became divisible by 4 AND not divisible by 100, OR divisible by 400. That single change fixed the entire dataset. There are a few things beginners miss when they first deal with this. One is that the leap year rule only applies to the Gregorian calendar, which went into effect in 1582. If you are working with historical dates before that, the Julian calendar applied a simpler rule: every year divisible by 4 was a leap year. The transition is messy because different countries adopted the Gregorian calendar at different times. Britain and its colonies switched in 1752, which is why your great-grandmother's birth certificate might have a date that literally disappears from the calendar. Russia did not switch until 1918, so Lenin's revolution is recorded as happening in October by the Gregorian calendar but in November by the Julian system still in use there.
Another thing people overlook is that calendar arithmetic is not just about counting days. It is about the specific problem you are trying to solve. If you are building a billing system that charges per day, you need to know whether you count February 29th or skip it. Most financial systems treat a year as 365 days for interest calculations and use actual/365 or actual/360 day count conventions depending on the product. The choice matters. Using the wrong convention on a mortgage calculation can shift the interest by a noticeable amount over thirty years. I have also seen people try to hardcode the leap year pattern instead of using the rule. They write out arrays or conditional branches for individual years. This breaks the moment they hit a year outside their hardcoded range. The divisibility rule is computationally cheap and handles any year, positive or negative, without maintenance. I switched one of our internal tools from a precomputed lookup table to the simple arithmetic check and the response time dropped from about 12 milliseconds per query to under 0.5 milliseconds. The lookup table was not wrong, but it was brittle and took up more memory than necessary. There are limits to what you can do with just the leap year rule. It does not account for the fact that the Earth's rotation is slowing down, which means we occasionally add leap seconds rather than leap days. That is a separate problem entirely and usually handled by the operating system time library. If you are writing code that touches system clocks, you should not implement your own time calculations from scratch. Use the built-in libraries for your language. Python's datetime module, JavaScript's Date object, Java's java.time package, and C#'s System.DateTime all handle leap years correctly if you feed them valid input. Writing your own calendar logic is a good exercise, but it is not something you should ship to production without extensive testing.
When I run into edge cases that the standard libraries do not cover, I usually fall back to a reference implementation rather than trying to reason through it myself. The International Standard ISO 8601 covers date and time representations and the leap year rules align with it. If you are validating dates from external sources, comparing against ISO 8601 compliance is a quick way to catch malformed input before it corrupts your data. I keep a small validation script that checks year, month, and day combinations against the leap year rule and rejects anything that does not fit. It runs in under a second for a batch of a thousand dates and has caught dozens of bad entries from partner systems over the years.
Get the Full Details
