Nøjagtighed og verifikation

Det her site sælger én ting: at tallene er rigtige. En dagslængde, et solopgangstidspunkt eller en formørkelsesdato er ikke noget, en læser kan efterprøve ved at kigge på siden. Man må tage os på ordet — og derfor skylder vi at gøre rede for, hvordan vi ved det.

Denne side beskriver, hvad der kontrolleres, hvordan, med hvilke tolerancer, og hvad kontrollen har fanget. Tallene i boksen øverst er ikke skrevet ind i hånden: de skrives af selve kontrolkørslen, hver gang sitet bygges. Vil du vide, hvordan tiderne beregnes frem for hvordan de kontrolleres, står det på sådan beregner vi tiderne.

To uafhængige beregninger, ikke én

Sitets egne tider beregnes med suncalc, direkte i browseren. Kontrollen beregner de samme størrelser med astronomy-engine — et andet bibliotek, skrevet af andre mennesker, bygget på en anden model af Solsystemet.

Det er hele pointen. Kontrollerede vi suncalc med suncalc, ville vi kun bevise, at koden er konsistent med sig selv, hvilket den altid vil være. To uafhængige implementeringer kan derimod være uenige, og når de ikke er det, betyder enigheden noget. På solopgang og solnedgang er de to ikke helt enige. Hvor uenige de er, står i panelet øverst på siden, hvor det måles ved hver kørsel i stedet for at være skrevet ned én gang. Forskellen er systematisk snarere end tilfældig: suncalc regner uden korrektionen mellem jordrotationens uregelmæssige tid og den ensartede tid, astronomien bruger, og det forskyder alle dens tidspunkter en anelse i samme retning. Mod nord vokser forskellen, fordi solen dér møder horisonten så fladt, at en brøkdel af en grad bliver til mange minutter — og på den ene dag om året, hvor polarnatten slutter, kan de to endda være uenige om, hvorvidt solen står op overhovedet.

Hvad der kontrolleres ved hvert build

Kontrollen er ikke en engangsgennemgang, men et script der kører som en del af hvert eneste build. Fejler det, bliver siden ikke udgivet. Det dækker:

• Sæsontabellerne. Hver række i tabellerne over vintersolhverv og jævndøgn genberegnes. Datoen skal ramme præcist — der er ingen tolerance på en dato.
• Måneformørkelser. Tidspunktet for største fase, formørkelsens type og dens umbrale størrelse. Desuden kontrolleres det, at ingen umbral formørkelse inden for datasættets eget tidsrum mangler.
• Solformørkelser. Det globale maksimum, typen, og for hver enkelt by de tre kontakttider samt hvor stor en del af solskiven der dækkes.
• Sitets egne tider. Solopgang, solnedgang og middagssol genberegnes for elleve steder fra Ushuaia til Longyearbyen, døgn for døgn gennem et helt år, og forskellen mellem de to biblioteker offentliggøres. Her er der ingen tolerance at bestå, for det er en måling og ikke en påstand — bygget standser først, hvis forskellen ændrer sig.

Tolerancerne, og hvorfor de er forskellige

En tolerance på nul lyder mest overbevisende, men ville være uærligt for de fleste af størrelserne. En formørkelses største fase er et øjeblik, der afhænger af, hvilken model man bruger for Månens bane, og to gode modeller kan lande et minut fra hinanden uden at nogen af dem tager fejl.

Derfor er tolerancen sat efter, hvad størrelsen faktisk kan bestemmes til: nul dage på en dato, minutter på en formørkelses faser, og en procent på dækningsgraden. En tolerance, der er sat løsere end det, holder op med at fange noget. En, der er sat strammere, fejler på støj — og et tjek, der fejler på støj, bliver slået fra, og tager de rigtige tjek med sig.

Fejl kontrollen har fanget

Kontrollen blev skrevet, fordi der var noget at fange. Alt herunder lå på sitet, var blevet læst igennem, og var forkert:

• Tre af fem rækker i tabellen over vintersolhverv angav 22. december for år, hvor solhvervet falder den 21.
• Fire af fem rækker i jævndøgnstabellen var en dag forkerte.
• Den næste måneformørkelses største fase var gemt 30 minutter for sent — og fejlen var kopieret over i begge sprog.
• En partiel måneformørkelse manglede helt i datasættet.
• Kontakttiderne for Edinburgh ved en solformørkelse lå syv minutter forkert.

Ingen af dem er subtile, når man regner efter. De overlevede, fordi ingen regnede efter. Samtlige urskiftsdatoer for efteråret i tabellen over sommertid og vintertid var også forkerte — de faldt alle på en mandag, på en side hvis egen tekst siger «den sidste søndag i oktober».

Hvad kontrollen ikke dækker

Det vigtigste ved en nøjagtighedsangivelse er, hvor den holder op med at gælde.

Tal i løbende tekst kontrolleres ikke automatisk. Scriptet læser tabeller og datasæt. Skriver nogen et klokkeslæt midt i et afsnit, fanger kontrollen det ikke. Dem regner vi efter i hånden, når de skrives.

Horisonten er ikke flad. Alle tider gælder for en matematisk horisont ved havoverfladen. Står du i en dal, bag en bakke eller på tyvende etage, ser du solen gå ned på et andet tidspunkt end det beregnede — og forskellen er langt større end beregningens egen usikkerhed. Det er den væsentligste kilde til afvigelse for de fleste brugere.

Refraktion er et gennemsnit. Beregningen bruger standardværdien for, hvor meget atmosfæren bøjer lyset. Ved usædvanligt tryk eller temperatur afviger den virkelige brydning, og solen kan stå op et minut eller to fra det beregnede.

Vejret er ikke medregnet. Skyer flytter ikke solen, men de flytter det tidspunkt, hvor du kan se den.

Hvis du finder en fejl

Så vil vi gerne vide det. Et forkert tal, der bliver stående, er værre end et tal, vi aldrig havde skrevet. Skriv via kontaktsiden — gerne med sted og dato, så vi kan regne efter på præcis det tilfælde.

Ofte stillede spørgsmål

Hvor nøjagtige er tiderne for solopgang og solnedgang?

Sitets tider er beregnet med suncalc, og ved hvert build sammenlignes de med astronomy-engine på tværs af elleve steder fra Ushuaia til Longyearbyen. Hvor langt fra hinanden de to lander, står i panelet øverst på siden — det måles, det påstås ikke. Den reelle usikkerhed for en bruger er større end forskellen mellem bibliotekerne og skyldes noget helt andet: højde over havet og terræn i horisonten. En bakke mod vest kan flytte den oplevede solnedgang flere minutter.

Hvad kontrollerer I automatisk?

Sæsontabellerne for solhverv og jævndøgn, tidspunktet for hver måneformørkelses største fase, dens type og størrelse, kontakttider og dækningsgrad for hver by ved solformørkelser, dagslængderne i bytabellerne, og sitets egne solopgangs- og solnedgangstider målt mod den uafhængige efemeride. Kontrollen kører ved hvert eneste build, og et build med et forkert tal fejler i stedet for at blive udgivet.

Hvorfor bruger I to forskellige beregningsbiblioteker?

Fordi to kopier af samme kode altid er enige. Sitet regner med suncalc, mens kontrollen regner med astronomy-engine, som er skrevet uafhængigt og bygger på en anden model. Når de to er enige, siger det noget. Havde vi kontrolleret suncalc med suncalc, ville kontrollen kun bevise, at koden er konsistent med sig selv.