What the engine computes, and where it stops

Everything here runs in your browser from published algorithms. No lookup tables, no server, no network. This page states what is computed properly, what is approximated, and — most importantly — how much the answer depends on the part that is approximated.

The chain of calculation

1. New moon. Meeus, Astronomical Algorithms, ch. 49: the mean lunation for index k, corrected by the full set of periodic terms plus thirteen additional planetary arguments. This is the accurate part.
2. Dynamical to universal time. The series gives Terrestrial Dynamical Time; observers live in solar time. The Espenak–Meeus ΔT polynomials convert between them.
3. Jerusalem local time. A fixed mean-solar offset for longitude 35.23° E.
4. Vernal equinox. Solar longitude from Meeus ch. 25, bisected to the moment it crosses zero.
5. Which lunation is Nisan. The first month whose full moon falls on or after the equinox.
6. Which evening Nisan 1 begins. The first sunset at which the moon is older than a chosen threshold — default 24 hours.

Steps 1 through 4 are real astronomy and are covered by the regression tests. Steps 5 and 6 are reconstruction: modern rules standing in for decisions that were, at the time, made by people looking at the sky and the barley.

ΔT is not a rounding error at this distance

The gap between dynamical and universal time is tiny today and large in antiquity. This engine's own values:

Nearly three hours. That is comfortably enough to move a sunset-boundary decision from one civil day to the next, and ΔT for the first century is itself an extrapolation from sparse eclipse records — it carries real uncertainty of its own, which this engine does not model.

The crescent rule controls the answer

This is the part worth dwelling on. A lunar month began when the new crescent was first seen. Sighting depends on the moon's age, its altitude and separation from the sun at sunset, atmospheric clarity, and the observer's horizon. Proper visibility criteria model these; this engine does not. It uses a single blunt proxy: the moon must be at least N hours old at sunset, with sunset itself approximated as 18:00 local.

Vary that one parameter across a plausible range and the celebrated result dissolves:

Read that table slowly. The two famous candidate years appear together only in a narrow band around 24 hours. Push the threshold to 30 hours — still an entirely defensible figure for naked-eye first sighting — and AD 33 vanishes. Pull it down to 18 and AD 30 vanishes instead. The result that gets quoted as an astronomical fact is, in this implementation, a function of a parameter nobody can pin down for a specific evening two thousand years ago.

Known limitations, stated plainly

• Sunset is fixed at 18:00 local. Real Jerusalem sunset in early April is nearer 19:00, and varies through the year. This shifts the effective crescent age.
• No visibility physics. No lag angle, no altitude or azimuth criterion, no atmospheric extinction, no Danjon limit.
• Full moon approximated as conjunction plus 14.77 days when selecting the Nisan lunation.
• The equinox search is bracketed to a fixed window in March — fine for this era, not a general-purpose routine.
• ΔT uncertainty is not propagated. The polynomial is used as if exact.
• The Islamic side is schematic: twelve lunar months per year from a fixed epoch, conjunction plus one day. It demonstrates drift; it is not a Hijri date converter.

What is actually guaranteed

A test suite pins the astronomy on every change: the canonical k=0 new moon, ΔT at 2000, solar longitude at the equinox, both candidate Fridays, and the Ramadan seasonal loop. Those tests exist so that the numbers cannot quietly drift while the site is edited around them.

What no test can guarantee is that the rules in steps 5 and 6 are the rules first-century Judea used. That is a historical question, and it is genuinely unresolved.