Japan's traditional calendar (the kyureki, an East Asian lunisolar calendar in its Tenpo form) blends the phases of the Moon with the motion of the Sun. Usually a fixed procedure assigns each month a unique name — but from autumn 2033 into 2034, the naive rules leave the lunar month names ambiguous. This is the "kyureki 2033 problem," a famous edge case in calendar computation where different publishers can disagree on the month names.
How lunar months get their names (new moons and major solar terms)
The Tenpo rules work in two steps. First, the day containing the instant of new moon (the saku) is day 1 of that month. Second, the name comes from the Sun's position. A "major solar term" (chuki) is a point where the Sun's ecliptic longitude is a multiple of 30° — the equinoxes and points like usui and kokuu in the East Asian scheme. The month containing a given major solar term takes the corresponding name (for instance, the month containing the spring equinox is lunar month 2). A month that contains no major solar term becomes a leap month (uruudzuki), repeating the previous month's number with a "leap" prefix. Normally this alone pins down every month name uniquely.
Why the rules break in 2033
But in late 2033 through 2034, the major solar terms fall in an unusual pattern. Because of how the length of a lunar month lines up with the spacing of the solar terms, months without a major term (leap-month candidates) can cluster, or a single month can contain two terms. As a result, the naive "name the month by its major solar term" rule no longer fixes the month names and the leap-month position uniquely. Starting from the same Tenpo principle, you can construct more than one self-consistent answer. That ambiguity is the kyureki 2033 problem.
Fixing it as "leap month 11" with the solstice-priority method
To resolve the ambiguity uniquely, Benri.dev uses the solstice-priority method (in Japanese, nishi-nibun, "two solstices and two equinoxes first"). The idea: always fix the month containing the winter solstice as lunar month 11, then place the leap month so it never breaks the anchors spring equinox → lunar month 2, summer solstice → month 5, autumn equinox → month 8. Under this rule, the ambiguous span in 2033 resolves uniquely to "leap month 11." Below are the new moons and month names as computed by our calendar engine.
| New moon (saku) | Lunar month name |
|---|---|
| 2033-07-26 (approx.) | Month 7, day 1 |
| 2033-08-25 (approx.) | Month 8, day 1 |
| 2033-09-23 (approx.) | Month 9, day 1 |
| 2033-10-23 (approx.) | Month 10, day 1 |
| 2033-11-22 (approx.) | Month 11, day 1 |
| 2033-12-22 (approx.) | Leap month 11, day 1 |
| 2034-01-20 (approx.) | Month 12, day 1 |
| 2034-02-19 (approx.) | Month 1, day 1 |
| 2034-03-20 (approx.) | Month 2, day 1 |
Because the month holding the winter solstice (late December) is fixed as month 11, the following month becomes "leap month 11," and months 12, 1 and 2 then line up cleanly.
When methods differ, rokuyo and festival dates shift
When calendars use different methods, the lunar month names, the rokuyo, and lunar-based annual festival dates can diverge between calendars. This matters in Japan because the rokuyo (the six-day "Taian / Butsumetsu" cycle) are fixed mechanically from "(lunar month + lunar day) mod 6" — see how rokuyo are decided. Shift the leap month by even one day and the rokuyo sequence shifts with it. Benri.dev's Rokuyo calendar derives the lunar date with this solstice-priority method first, then computes the rokuyo, giving consistent results across 1900–2099.
FAQ
Why does this only happen around 2033?
Can my calendar's month names differ from yours?
The month names and new-moon dates in this article are computed by our own calendar engine (as of 2026-07-16).