2026.08.20
Headers in this release
| Header | Version | Changed since 2026.08.19 |
|---|---|---|
prayertimes.h |
v0.2.1 |
Yes |
hijri.h |
v0.1.0 |
No |
timezone.h |
v0.1.0 |
No |
The tag is a calendar date and the headers carry their own semantic versions, so these numbers are not meant to match. Pin a download to the tag. Reason about compatibility from the header version.
prayertimes.h goes from v0.2.0 to v0.2.1. A patch, not a minor: struct PrayerTimes, MethodParams and every function signature are unchanged, so anything compiled against v0.2.0 still compiles and still links. Only values returned inside the polar circle move.
If you pinned 2026.08.19, upgrade. That release reported prayers out of order at high latitude and returned a formula artifact as a prayer time, and its header calls itself v0.2.0 exactly as the fixed one used to, so a vendored copy cannot be told apart by reading it.
Fixed: prayers came back out of order inside the polar circle
A method carrying a reference latitude borrowed sunrise and sunset from that latitude but left fajr, isha and asr solved at the real one, then reported both in a single schedule.
2026-01-01 at 78.22 N, MWL
fajr 7.546 dhuhr 12.012 asr 14.735 maghrib 16.430 isha 16.121
isha 18.5 minutes before maghrib
At that latitude the Sun peaks near -11.2 degrees, so it never crosses -0.833 and there is genuinely no sunset, but it does cross -17, so isha is a real event. Maghrib came from 45 N and isha from 78 N.
41 days of 2026 at Longyearbyen under MWL, all in the polar night. The whole day is now solved at one latitude.
Fixed: asr was reported where the Sun casts no shadow
The Sun's greatest altitude on a day is 90 - fabs(lat - decl), so a separation of 90 degrees or more means it never rises and no shadow of any ratio is cast. The formula did not say so. Past 90 degrees its tangent turns negative, it returned a negative shadow altitude, and that was solved into a plausible looking time.
2026-01-01 at 78.22 N, Sun peaks at -11.235 deg
Kemenag asr altitude -13.922 deg asr 14:47 reported as a prayer time
This was the one field that survived an isfinite() check on days where fajr, maghrib and isha were all correctly unavailable, so a caller filtering per field would have displayed it. A wrong time is worse than no time.
2926 points of a 40810 point grid were affected. Now none.
Fixed: the substituted isha could precede maghrib
Moonsighting sets maghrib 3 minutes after sunset and takes isha as one seventh of the night. On a bright night of 19.5 minutes one seventh is 2.8 minutes, so the fixed offset overtook the fraction.
Tromso 2026-05-18
maghrib = sunset + 3 min = 23.590332
isha = sunset + night/7 = 23.586724 13.0 seconds early
The evening substitution now measures from maghrib. Every method whose maghrib is sunset is unaffected, because for them the two anchors are the same instant.
What did not move
No published-table comparison changed across any of the three fixes. Each was verified by diffing all 702 comparison lines against the previous state, rather than by comparing the residual histogram, because an unchanged histogram does not prove that no individual time moved.
The residual distribution stands at 369 checks at 0 minutes, 326 at 1 and 7 at 2.
Known and deliberate
A 40810 point grid, latitudes -85 to 85 in steps of 5, every seventh day of 2026, all 22 methods:
days with prayers out of order 0
asr finite with no possible shadow 0
days with a NaN field 5434
days with a field outside 0..24 69
The last two are by design. 20 of the 22 methods return non-finite prescribed times inside the polar circle because their authority publishes no rule for that case, tracked in #51. Values outside 0 to 24 carry a day offset that the double is the only thing recording, documented on the struct and tracked in #56.
New test
The five prescribed times are now asserted to stay in order at five locations across all 22 methods, not only the two that carry a reference latitude today. Checks go from 748 to 756.