Oq É Um Ano Bissexto

Understanding leap years beyond the basic rule

Most people know that a leap year adds an extra day to February, but the actual calculation is messier than the simple "every four years" explanation you get in school. The solar year is about 365.24219 days long, which means if we only added a day every four years without corrections, the calendar would drift by roughly one full day every 128 years. Over centuries, that drift becomes noticeable. The Gregorian rule is: a year is a leap year if it is divisible by 4, unless it is divisible by 100 but not by 400. So 2024 is a leap year. 1900 was not, despite being divisible by 4, because it is divisible by 100 and not by 400. 2000 was a leap year because it satisfies the 400 exception. 2100 won't be. This rule keeps the calendar within about 26 seconds of the actual solar year per century, which is acceptable for civil purposes. I spent several hours debugging a scheduling system last year where birthdays and contract anniversaries were drifting by a day every few decades. The issue traced back to the application using a simplified leap year check that treated every year divisible by 4 as a leap year. It worked fine for years between 2000 and 2099 but broke badly for edge cases and historical dates going back to 1900. The fix was replacing the custom logic with a standard library function that implements the full Gregorian rule.

Here is one thing most people miss: the Excel date bug from 1900. Microsoft Excel incorrectly treats 1900 as a leap year when it wasn't. This was inherited from Lotus 1-2-3 and kept for compatibility. If you are doing date arithmetic across spreadsheet data and historical records, this can throw off calculations by one day for any date between March 1, 1900 and February 28, 1900. It is a well-known issue but still catches people off guard.

How it works in practice

When writing code to determine leap years, use the standard conditional rather than rolling your own. In most languages, this is a one-liner: year modulo 4 equals zero, excluding years modulo 100 equals zero unless year modulo 400 equals zero. Python's calendar.isleap(), JavaScript's built-in date handling, and similar functions in other languages already encode this correctly. Reinventing it introduces risk. If you are generating calendars or scheduling systems, always account for the Gregorian reform. Dates before October 1582 require special handling depending on your use case. Countries adopted the Gregorian calendar at different times — Britain and its colonies switched in 1752, Russia in 1918. If your application deals with historical data, a single leap year rule will not cover everything accurately. Another practical consideration: the astronomical definition and the civil definition do not always align perfectly. The Earth's rotation is gradually slowing, which means leap seconds exist separately from leap years. For most applications this separation does not matter, but if you are working with high-precision timing systems, conflating the two is a mistake.

There is no universal downloadable tool for this since the logic is so small, but if you need to validate dates in bulk, a simple script that applies the Gregorian rule and flags anomalies like February 30th or invalid historical transitions will save time. The rule itself is stable — the next year that will not be a leap year despite being divisible by 4 is 2100, and the one after that follows the same pattern in 2200 and 2300.