SalahTimes 0.1.0

The first release of SalahTimes: prayer-time calculation in Swift, written from published astronomy and each method's published definition, with no dependencies. It computes Fajr, sunrise, Dhuhr, Asr, sunset, Maghrib, Isha and the night's middle and last third for one civil day in a time zone, reports events that don't occur instead of inventing them, and gives the Qibla.

Documentation: https://salah-kit.github.io/SalahTimes/documentation/salahtimes
Specification: docs/algorithm.md · Methods and sources: METHODS.md · Validation: docs/validation.md · Vectors: Vectors/README.md

Proven

• Swift Package Index, 2026-10-14. SalahTimes is listed after PackageList PR #15688 was accepted. Its compatibility builds remain pending: none had completed on 2026-10-15.

• Post-release validation update, 2026-10-14. The runtime and 0.1.0 tag are unchanged. The current validation report adds 144 JPL DE441 solar events on 48 site-days (maximum difference 5.19 seconds), complete official 2026 Dubai/Abu Dhabi tables, and an automated OCR comparison of all 365 days of Qatar Calendar House's 2025 publication. The source/methodology limits are explicit; this does not claim polar-transition/elevation accuracy or visual review of every Qatar card.

• Vectors. 1,270 JSON vectors, generated by an independent Python implementation of docs/algorithm.md, pass on macOS and Linux; the engine and the reference agree within 0.51 seconds on every event. They cover every preset, polar day and night and the days around them, the first and last nights of a twilight season, the date line (including the day Samoa skipped in 2011), daylight saving changes, Isha after midnight, the Ramadan rule, crossings near the poles, and the years 1000 to 3000. NOAA's solar calculator agrees with the reference within 3.7 seconds for sunrise, sunset and transit from 1900 to 2100.

• adhan-swift parity. All eight of adhan-swift's test timetables agree within one minute for every prayer, except four times, each explained: two Isha times in Ankara (Diyanet's Isha isn't a pure 17° angle) and Fajr and sunrise on one day in Kuwait City (that row is 1.6 minutes late for both).

• Official timetables, every day of 2026: the Moonsighting Committee's London calculator matches to the minute on 91–97% of days for every prayer but Asr (74–78%); Diyanet (Istanbul, Ankara) and Umm al-Qura (Makkah, Riyadh) within a minute on 90–100% of days; MUIS (Singapore) and Kemenag (Jakarta) within a minute on 99–100%. JAKIM's zone WLY01 runs 1 to 3 minutes later than JAKIM's documented method; docs/validation.md explains the difference and gives a zone fit.

• Self-consistency. At 30,952 computed events from 60° S to 60° N, an independent solar model puts the Sun within 0.013° of the defining altitude, and Asr's shadow ratio matches the madhab.

• Properties. Events stay in order for seven presets from 65° S to 65° N on every day of 2026, change smoothly from day to day, don't change across daylight saving time, behave as specified in polar day and night at Tromsø and Longyearbyen, work at the equator and the date line, and mirror between Ushuaia and Punta Arenas and their northern counterparts within 8 seconds. A wider scan, every preset from 66° S to 70° N, records where order breaks down (see Known limitations).

• Speed. About 9 to 11 µs per day and 28 to 32 µs for 48 hours in a release build on an Apple M2 Pro.

• CI. macOS (build, tests, builds for iOS, watchOS, tvOS and visionOS, the example under both default-isolation settings, DocC with warnings as errors), Linux (swift:6.4.0-noble: build, tests, example) and lint.

Pending

• Comparisons with official timetables that haven't been checked yet, among them Kuwait's current timetable and method, Qatar Calendar House's 2026 calendar, Egypt's and Iran's: #5. The 2025 Qatar and 2026 UAE comparisons are complete, as the current validation report describes.
• Spot-checks against local mosque timetables: #6.
• A reading of METHODS.md's sources in their original languages, several of which are secondary (Umm al-Qura, Kemenag's ihtiyat, MUIS's angles, Tehran's Isha angle, Kuwait). Numerical agreement doesn't establish what each authority's text says: #7.

Known limitations

• The retained 2018-calibrated Dubai preset gives Asr 1–3 minutes later than the official 2026 Dubai/Abu Dhabi tables. A tested city-specific user adjustment of −2 minutes brings all six rounded prayer times within one minute for those 730 city-days; it is not a published national rule or a silent preset change. Qatar's 2025 table retains 90-minute Isha in Ramadan; a 120-minute override does not reproduce that table.
• Elevation is ignored: sunrise and sunset use a −0.8333° horizon everywhere.
• Presets follow an authority's documented rules; JAKIM's zone timetables add 1 to 3 minutes that aren't documented. MUIS and the UAE publish only timetables, so their presets are fitted to them.
• SalahTimes applies each rule as specified and never reorders events. Beyond about 64°, Isha by interval can fall after the next Fajr, and precautionary minutes can put events out of order when nights are very short; Tehran's Maghrib and Isha can coincide from 58°. docs/validation.md lists every case the scan found.
• Every event belongs to the day you asked for, even when its instant falls outside that civil day: Isha, and near the polar circles sunset and Maghrib, can fall after midnight, and a Fajr near solar midnight can fall before the day begins where the clock runs behind the Sun. That is common with middleOfTheNight at high latitudes. Apps that need events inside the civil day must check (RFC 0001, decision 2).
• Within about a degree of a pole, the model's premise that the Sun is highest at the transit and lowest at the antitransit fails, and crossings can go unreported; treat events there as unreliable.
• Diyanet's own high-latitude rules and its 16° Isha for calendars abroad, and the Moonsighting Committee's slide-down to 60°, aren't implemented.
• The API is below 1.0 and may change in minor releases, through RFCs.