How CatchClock calculates bite times
Every bite window on this site is two hours wide around the Moon's meridian transit, or one hour wide around moonrise and moonset. Nothing on the page is measured — it is an astronomical calculation wrapped in a convention that is a century old. This page gives you the formula, the model, the references we check against, and the cases where the whole idea stops being worth anything.
The formula, in one paragraph
A major period is the two hours centered on the Moon's meridian transit: one hour before the crossing, one hour after. There are normally two a day, because the Moon crosses the meridian twice — once overhead (upper culmination) and once underfoot (lower culmination). A minor period is the one hour centered on moonrise and the one hour centered on moonset: thirty minutes either side. That is the entire formula. There is no weighting, no proprietary score, and no adjustment we decline to describe.
The idea comes from John Alden Knight, who published solunar tables in 1926. The window widths — sixty minutes either side of a transit, thirty either side of a moonrise — are his convention, kept by every publisher since. They are not a result. Nothing in astronomy says fish stop feeding sixty-one minutes after the Moon crosses your meridian. Solunar theory has no rigorous scientific confirmation behind it: it is a prediction, not a measurement, and a page that hides that is selling you a precision it does not have.
Meridian transit, not peak altitude
The model has a name: meridian transit, found by solving for hour angle 0 (upper culmination) and hour angle 12 hours (lower culmination) at the city's own latitude and longitude. It is not "the moment the Moon is highest in the sky", and the distinction is the single most consequential technical choice on this site. The Moon's declination moves by as much as 5° in a day, so the instant of peak altitude drifts away from the meridian crossing.
8.6 min
Peak altitude is the tempting implementation, because almost every astronomy library hands you an altitude and almost none hands you an hour angle. It is also wrong by up to 8.6 minutes on the lower culmination and 8.0 minutes on the upper, and the worst case in our grid is the northernmost city we publish — the Anchorage bite windows, where a high latitude and a fast-moving declination pull the two moments furthest apart. We solve for the hour angle directly with astronomy-engine 2.1.19, and we verify it the only honest way: a completely separate search for the moment the Moon's azimuth crosses the meridian, written against a different library, agrees with our result to within 1.1 seconds across the same 760 events.
What goes into the calculation
Everything is computed when the site is built, from static inputs, with no request to any API at page load. That is a deliberate constraint: a page that calls a weather service can break in front of a reader standing on a boat ramp with one bar of signal. It also means nothing about the reader enters the calculation — the inputs are a coordinate pair and a time zone, and the privacy policy sets out what the site does and does not collect.
| Input | What we use | Why it is specified this way |
|---|---|---|
| Position | City-center latitude and longitude, two decimals | 0.01° of longitude is 2.4 seconds of time — far below the minute a table shows |
| Clock | The city's IANA time zone, not a fixed UTC offset | An offset is wrong for half the year in every zone that shifts for daylight saving |
| Day boundary | Local midnight to midnight of the next civil date | Adding 24 hours silently loses or duplicates events on shift days: 76 city-days a year in our grid are 23 or 25 hours long |
| Ephemeris | astronomy-engine 2.1.19 | Rise and set use topocentric parallax, apparent disc radius and 34′ of refraction, not a flat geometric horizon |
| Tides | Harmonic constants published by a NOAA CO-OPS station, matched to a city by hand | No harmonic station within 25 km means no tide block at all, rather than a table describing different water — and never an automatically picked "nearest" station |
| Weather | Not modeled | Pressure, fronts and water temperature are absent from the model; saying so beats publishing a number we did not compute |
What we check the numbers against
A calculation nobody checks is an opinion. Below is every reference we compared against on 2026-08-10, including the one that did not answer — because the status of a reference is part of the result.
| Reference | Status on 2026-08-10 | Agreement with our numbers |
|---|---|---|
| Independent meridian search (azimuth crossing) | Ran locally, 760 culminations | Within 1.1 s |
| suncalc 2.0.1, a separate implementation | Ran locally, 39 cities × 10 days | Sunrise and sunset +1 s / −3 s; civil twilight 0 s; moonrise and moonset +1 s / −3 s |
| open-meteo daily sunrise and sunset | Responded | Matched to the minute |
| api.sunrise-sunset.org | Responded | Differs by 67–88 s — it uses a fixed 90.833° zenith, a different model. Not an error on either side, and not something we test for equality |
| NOAA CO-OPS tide predictions, all five stations this site carries | Responded, 8-day window; the reply is committed and re-checked on every build | 155 of 155 high and low waters matched. Timing agrees to 0.42 min on average at Charleston and 4.24 min at Anchorage, the hardest case; heights stay within 0.09 ft everywhere except Anchorage, worst 0.91 ft against a 29 ft range |
| U.S. Naval Observatory | Did not respond from our build environment — the request timed out | The gold standard, and the reference we intend to spot-check against by hand — never wired into the build. No such check has been run yet: this site has not been published, so there is no review history to report |
155 of 155
The last row is the one worth reading twice. USNO is the reference everyone in this field cites, and its API would not answer the machine that builds this site, so it is not in our automated checks and we will not imply that it is. The same discipline applies to the sunrise-sunset.org row: an 88-second difference against a service that models the Sun differently is not an error to chase, and turning it into a passing test would only mean testing that two wrongs agree.
One reference is deliberately used for solar times only, and the reason is worth stating because it is invisible from the outside. In suncalc 2.0.1 the moon-times call scans a UTC day and overwrites whatever instant it is handed, so for Seattle on 2026-08-10 it returns a moonset of 18:59 — an event that belongs to the previous local day — where the correct answer for that local day is 19:40. Forty-one minutes of error, with nothing in the returned value to flag it. That is why every lunar number here comes from an hour-angle solution instead, including the Seattle bite windows, and why local days on this site run from local midnight to local midnight rather than from a fixed offset.
Where the data thins out
Missing events are normal, not a bug in the page you are looking at. The Moon rises roughly fifty minutes later each day, so on some local days it never rises at all, and on some it never sets. On other days there is only one meridian crossing inside the local day instead of two.
6.8%
Where an event does not exist, the table shows an em dash. It never shows 00:00, and it never quietly borrows yesterday's value — both are ways of turning "this did not happen" into a number a reader would plan a morning around. The count of major periods is a variable on every page, never a fixed pair of rows.
When the solunar method is the wrong tool
On tidal salt water, go to the tide first. Moving water at a pass or an inlet drives the bite harder than any lunar window, and a solunar table is not a substitute for station predictions. A city page here carries tide numbers only when a NOAA harmonic station sits within 25 km of that city's main water; when none does, the page says nothing about tides, and the station's own page is the right place to look rather than a nearby proxy. Galveston Bay is the clearest case: the Houston bite windows sit on a largely diurnal Gulf tide — often one high and one low a day — with no station mapped by hand, so that page carries no tide table at all.
Weather beats the Moon. A passing front, a fast pressure drop or a 10°F swing in water temperature will overwhelm the effect these windows describe, and none of the three is in the model. Treat a major period as a tiebreaker for when to fish on a day you already chose, not as a reason to choose the day.
Local knowledge beats a global model. A drawdown, a stocking schedule, a spawn that runs two weeks early this year — a regional forum or a state biologist knows these; a calculation from coordinates cannot.
We are not a regulatory source. Seasons, size limits and bag limits change, and restating them on a page that updates on our schedule instead of the agency's would be worse than useless. Every city page links its state agency directly, and that link is the only correct answer to a question about legality.
61.2° N
Far north, the model needs a different page. Above roughly 61° north, days without a sunrise or without a moonset stop being edge cases and become the norm, and the window logic here has not been validated there. Our northernmost published city sits at 61.2°, and we do not publish above it. If that is where you fish, use a source built for high latitudes.
What this method is good for is narrow and real: it tells you, for a specific place and a specific day, the hours in which a century-old convention says feeding activity peaks — computed correctly, checked against independent references, and stated without dressing it up as science it is not. The same numbers, and the same caveats, sit behind every page in the city fishing forecast grid and behind the general guide to best fishing times.