Why No Number System
Can Fix the Calendar
From base-10 to base-60, humanity has tried every mathematical trick to make Earth's orbit divide into neat, equal months. Here's why it never works — and what that tells us about the limits of human systems imposed on nature.
In 1582, Pope Gregory XIII's team of astronomers and mathematicians introduced the Gregorian calendar — a system of leap years governed by three simple rules that's kept our dates aligned with the seasons for over four centuries. But what if there was a better way? What if we just chose the right number base — decimal, octal, hexadecimal — and built a cleaner calendar from scratch?
I went down this rabbit hole, systematically testing every number base I could think of against the hard constraints of orbital mechanics. The journey was fascinating, the conclusion humbling. Let's walk through it.
The Non-Negotiable Number
Before we try anything clever, we need to respect the one number we can't change: Earth takes 365.2422 days to orbit the Sun. Not 365. Not 360. Not any round number in any base. This is the tropical year — the time between two vernal equinoxes — and it's dictated by gravity and orbital mechanics, not mathematics or human preference.
The Gregorian calendar handles this with three leap year rules: divisible by 4 (leap), divisible by 100 (not leap), divisible by 400 (leap again). This gives an average year of 365.2425 days — off by just 0.0003 days per year, or about one day every 3,236 years. It's boring. It's inelegant. And it works.
The question is: can we do better?
Attempt 1: The 13-Month Calendar
The idea is seductive in its simplicity: 13 months of exactly 28 days each. Every month has exactly 4 weeks. Every month starts on Monday and ends on Sunday. Scheduling becomes trivial — the 15th is always a Monday, your birthday falls on the same weekday forever.
13 months × 28 days = 364 days
// The reality
Tropical year = 365.2422 days
Shortfall per year = 1.2422 days ← worse than Gregorian's 0.2422
This is actually a harder problem than what the Gregorian system solves. The current calendar only needs to account for 0.2422 excess days. The 13-month version is 1.2422 days short — meaning you need an "extra day" bolted on every single year, plus an additional leap day for the fractional part.
The analogy: The Gregorian calendar is standing on a ledge that's only 0.24 days too narrow. The 13-month proposal jumps down to a ledge that's 1.24 days too narrow. You've traded a small balancing problem for a bigger one.
This isn't hypothetical — it's been tried. The International Fixed Calendar (proposed by Moses Cotsworth in 1902) used exactly this structure, with a "Year Day" outside the week/month system at the end of each year, and a "Leap Day" in June. Kodak actually used it internally from 1928 to 1989 for accounting. But those "orphan days" that belong to no month and no weekday break the very symmetry that made the system appealing.
Elegant structure, but creates a larger remainder problem than Gregorian. Requires intercalary days that break the clean weekly pattern — the system's entire selling point.
Attempt 2: The "Pocket Year"
What if, instead of adding a stray day every year, we saved the shortfall? Pocket the 1.2422 days each year, and when the pocket accumulates to a full 364 days, withdraw it as an entire bonus year — a "pocket year" with a special name, like how we have leap years.
364 ÷ 1.2422 = 293.19 years
// Check after 293 years
293 × 1.2422 = 363.96 days ← not quite 364
// Check after 294 years
294 × 1.2422 = 365.21 days ← overshot
The pocket never fills to exactly 364 days, so you'd still need a secondary correction rule on top of the pocket year — mirroring the Gregorian complexity you were trying to escape.
But the real killer is practical. This is like saying "instead of adjusting your watch by a few seconds every day, I'll let it drift for 293 years and then reset it all at once." Seasons would drift by up to half a year mid-cycle. Farmers in year 150 of the cycle would be planting in what the calendar calls summer but is actually winter. The Gregorian system's genius is that the maximum drift is never more than one day before a leap day corrects it.
The analogy: It's like saving up all your software patches for 293 years and deploying them in one massive update, hoping nothing drifts into an unusable state in the meantime. Continuous deployment beats big-bang releases — in calendars too.
Conceptually creative, but trades frequent tiny corrections for rare catastrophic ones. Maximum seasonal drift: ~6 months. Completely unusable for agriculture, navigation, or any purpose tied to actual seasons.
Attempt 3: The Decimal Calendar
If our number system is base-10, shouldn't our calendar be too? Ten months, ten-day weeks, everything clean and metric. This was the dream of the French Revolution.
10 × 36 = 360 days → short by 5.24 days/year
// Option B: 10 months × 37 days
10 × 37 = 370 days → over by 4.76 days/year
// The real problem
365 ÷ 10 = 36.5 ← that half-day poisons everything
The French actually did it. The Republican Calendar (1793–1805) had 12 months of 30 days each (three 10-day "décades" per month), plus 5–6 intercalary days called sans-culottides. They even decimalized the day itself: 10 hours of 100 minutes of 100 seconds.
Workers hated it. Ten-day weeks meant nine working days between rest days instead of six. The system lasted 12 painful years before Napoleon scrapped it.
365 ÷ 10 = 36.5 — that half-day remainder poisons every combination. Still needs intercalary days (more of them than Gregorian), plus workers despised the 10-day work week. Historically tested and failed.
Attempt 4: Every Other Base
If base-10 doesn't work, what about the bases beloved by programmers and mathematicians? Octal (8), hexadecimal (16), duodecimal (12), or the ancient Babylonians' sexagesimal (60)?
Let's be systematic about this.
| Base | Structure | Total | Gap | Patch Needed | Status |
|---|---|---|---|---|---|
| Base-8 | 8 months × 45 days | 360 | −5.24 days | 5–6 intercalary days | Worse |
| Base-10 | 10 months × 36 days | 360 | −5.24 days | 5–6 intercalary days | Worse |
| Base-12 | 12 months × 30 days | 360 | −5.24 days | 5–6 intercalary days | Worse |
| Base-13 | 13 months × 28 days | 364 | −1.24 days | 1–2 intercalary days | Closer |
| Base-16 | 16 months × 22 days | 352 | −13.24 days | 13–14 intercalary days | Much worse |
| Base-60 | 12 months × 30 days | 360 | −5.24 days | 5–6 intercalary days | Worse |
| Gregorian | 12 months × 30/31 days | 365 | −0.24 days | 1 day every 4 years* | Best fit |
* With 100/400 correction rules. Average year = 365.2425 days.
Notice the pattern? Nearly every "clean" base produces months that total 360 — because 360 is the number that plays nicely with almost everything. But 360 is 5.24 days short of reality. The Gregorian system's uneven months (28, 30, 31) are ugly precisely because they stretch to reach 365, which is as close to 365.2422 as you can get with whole days.
The analogy: Imagine you have a rope that's exactly 365.2422 meters long and you need to cut it into equal pieces with zero waste. It doesn't matter if you try 10 pieces, 8 pieces, 16 pieces, or 12 pieces — none of them give you whole numbers, because 365.2422 isn't a clean multiple of any small integer.
The Graveyard of Calendar Reforms
This isn't a new obsession. Humanity has been trying to crack this for millennia. Every civilization that developed mathematics eventually took a swing at the calendar — and every one of them had to patch around the same stubborn remainder.
Why No Base Can Solve This
Here's the fundamental insight, and it's surprisingly simple once you see it.
Earth's orbital period (365.2422 days) and its rotational period (1 day) have a ratio that is irrational-adjacent — it doesn't reduce to a clean fraction in any base. Changing the number base changes how you write the number, not what the number is. 365.2422 in decimal is 555.1736… in octal, 16D.3E0… in hexadecimal, and 6;5;14;31… in sexagesimal. In every case, the fractional part is messy and non-terminating.
A number base is like a language. Translating "365.2422" from English to French doesn't make the number rounder. The mathematical relationship between Earth's orbit and its rotation was set by the physics of the early solar system — by angular momentum, gravitational interactions, and tidal forces spanning billions of years. These processes had no obligation to produce numbers friendly to primate-designed counting systems.
Where Alternate Bases Do Work: Inside the Day
Here's what's interesting: alternate bases work beautifully for sub-day timekeeping, because within a day, you define the units yourself. A "second" isn't dictated by astronomy — it's an arbitrary subdivision of a day. You can pick a base with maximal divisibility and it works perfectly because there's no external physical constant to fight.
This is exactly why base-60 survived for 4,000 years in our hours and minutes. 60 is the smallest number divisible by 1, 2, 3, 4, 5, and 6 — it has twelve factors total. It's why an hour splits cleanly into halves, thirds, quarters, fifths, sixths, tenths, and twelfths. No other small number can do this.
The French tried to decimalize the day too (10 hours, 100 minutes, 100 seconds), and while it was internally consistent, it was worse for practical division. Want to split a decimal hour into thirds? That's 33.333… minutes. In sexagesimal, it's exactly 20 minutes. The Babylonians understood something the French revolutionaries didn't: divisibility matters more than a tidy base.
Base-60 thrives for time-of-day because it's purely subdividing a known unit. Calendar design fails with every base because it's trying to reconcile two independent physical constants (rotation and orbit) that have an irrational ratio.
The Developer's Answer: Just Count Days
If you're a programmer, you already know the real answer — because you use it every day. Unix epoch time is a continuous count of seconds since January 1, 1970. No months. No years. No weeks. No leap year rules. Just a single monotonically increasing integer.
Astronomers reached the same conclusion centuries earlier with Julian Date — a continuous day count since January 1, 4713 BC. Need to calculate the time between two events? Subtract two numbers. No need to wonder about month lengths, leap years, or century exceptions.
"How many days between March 15, 2024 and November 7, 2025?"
→ Count days in March, account for April-October,
check if 2024 is a leap year, handle the partial
months... carry the one...
// The epoch way:
1730937600 − 1710460800 = 20476800 seconds
20476800 ÷ 86400 = 237 days ✓
This is humanity's quiet admission that the cleanest timekeeping simply abandons human-friendly divisions and counts the base unit as one continuous number. Every time you call Date.now(), you're using a system that doesn't fight the irrationality — it just ignores it.
The Lesson
After testing 13-month calendars, pocket years, decimal time, octal proposals, and every base from 8 to 60, the conclusion is both humbling and satisfying: no number system can fix the calendar, because the problem isn't mathematical — it's physical.
Earth's orbit doesn't speak decimal, hexadecimal, duodecimal, or sexagesimal. It speaks in the language of gravitational mechanics, and the number it produces — 365.2422 — is irreducibly messy in every human notation. The Gregorian calendar's uneven months and awkward leap year rules aren't a failure of imagination. They're the closest thing to a clean solution that the laws of physics allow.
Sometimes the boring, patched, historically contingent system isn't just good enough — it's the best anyone can do. And sometimes, if you really need precision, the right move isn't to find a better calendar. It's to stop using calendars altogether and just count the days.