Accuracy and verification

This site sells one thing: that the numbers are right. A day length, a sunrise time or an eclipse date is not something a reader can check by looking at the page. You have to take our word for it — which is why we owe you an account of how we know.

This page sets out what is checked, how, to what tolerance, and what the checking has caught. The figures in the panel above are not typed in by hand: they are written by the verification run itself, every time the site is built. If you want to know how the times are computed rather than how they are checked, that is on how we calculate the times.

Two independent calculations, not one

The site's own times are computed with suncalc, in your browser. The verification recomputes the same quantities with astronomy-engine — a different library, written by different people, built on a different model of the solar system.

That is the entire point. Checking suncalc with suncalc would only prove the code is consistent with itself, which it always will be. Two independent implementations can disagree, so when they do not, the agreement carries information. On sunrise and sunset the two land within 12 seconds of each other.

What is checked on every build

The verification is not a one-off review. It is a script that runs as part of every build, and if it fails the site does not ship. It covers:

• The season tables. Every row of the solstice and equinox tables is recomputed. The date has to match exactly — there is no tolerance on a calendar date.
• Lunar eclipses. The instant of greatest eclipse, the type, and the umbral magnitude. It also checks that no umbral eclipse falling inside the dataset's own date range is missing from it.
• Solar eclipses. The global peak, the type, and for each listed city the three contact times and the fraction of the sun covered.

The tolerances, and why they differ

A tolerance of zero everywhere would sound more convincing and would be dishonest for most of these quantities. The moment of greatest eclipse depends on the lunar theory you use, and two good models can land a minute apart without either being wrong.

So each tolerance is set to what the quantity can actually be pinned down to: zero days on a date, minutes on eclipse phases, one percent on obscuration. Set looser than that, a check stops catching anything. Set tighter, it fails on noise — and a check that cries wolf gets switched off, taking the honest checks with it.

Errors this has caught

The verification was written because there was something to catch. All of the following were published, had been read over, and were wrong:

• Three of five rows in the winter solstice table gave 22 December for years when the solstice falls on the 21st.
• Four of five rows in the equinox table were a day out.
• The next lunar eclipse's greatest phase was stored 30 minutes late — and the error had been copied into both languages.
• A partial lunar eclipse was missing from the dataset entirely.
• Edinburgh's contact times for a solar eclipse were seven minutes late.

None of that is subtle once you compute it. It survived because nothing computed it. The same was true of the autumn clock-change dates on daylight saving time: every one was wrong, and every one fell on a Monday, on a page whose own text says the change happens on a Sunday.

What the verification does not cover

The most useful thing an accuracy claim can do is say where it stops.

Numbers written in prose are not checked automatically. The script reads tables and datasets. If someone writes a time into the middle of a paragraph, the check will not see it. Those are worked out by hand when written.

The horizon is not flat. Every time assumes a mathematical horizon at sea level. In a valley, behind a hill, or twenty floors up, you will see the sun set at a different moment than the computed one — and that difference is far larger than the calculation's own uncertainty. For most readers this is the dominant source of disagreement.

Refraction is an average. The calculation uses the standard value for how much the atmosphere bends light. Under unusual pressure or temperature the real bending differs, and the sun can rise a minute or two away from the computed time.

Weather is not modelled. Cloud does not move the sun, but it certainly moves the moment you can see it.

If you find an error

We would like to know. A wrong number left standing is worse than one we never published. Get in touch through the contact page, ideally with the place and date, so the specific case can be recomputed.

Frequently asked questions

How accurate are the sunrise and sunset times?

Sunrise and sunset times are computed with suncalc and agree with astronomy-engine, an independent implementation, to within 12 seconds. The real uncertainty for a reader is larger than that and comes from somewhere else entirely: elevation and the terrain on your horizon. A hill to the west can move the sunset you actually see by several minutes.

What is checked automatically?

The solstice and equinox tables, the instant of greatest eclipse for every lunar eclipse along with its type and umbral magnitude, and the contact times and obscuration for every city listed for a solar eclipse. The check runs on every build, and a build containing a wrong number fails rather than shipping.

Why use two different astronomy libraries?

Because two copies of the same code always agree. The site computes with suncalc; the check computes with astronomy-engine, which was written independently and uses a different model. When those two agree it means something. Checking suncalc against suncalc would only prove the code is consistent with itself.