feat(eclipses): surface upcoming solar eclipses and alert on major ones - #166
Open
daneden wants to merge 3 commits into
Open
feat(eclipses): surface upcoming solar eclipses and alert on major ones#166daneden wants to merge 3 commits into
daneden wants to merge 3 commits into
Conversation
Solstice had nothing to say about the most dramatic thing the sun ever does. This adds a detail-view section for an upcoming solar eclipse visible from a location, and two local notifications for eclipses that cover most of the sun. The maths is new ground: NTSolar is sun-only, and eclipse circumstances need the moon. EclipseCalculator follows the precedent SolsticeCalculator already sets — a stateless enum holding a Meeus port with its own Julian day helpers — using chapter 25 for the sun, chapter 47 for the moon and chapter 49 to step lunation by lunation. Positions are converted to topocentric coordinates, which is what makes an eclipse a local event at all: the moon's horizontal parallax is nearly a degree, comparable to the whole geometry involved. NTSolar is not reused because its solar model neglects aberration and costs about an arcminute, roughly 6% of eclipse magnitude. Checked against NASA's published circumstances. Gamma for 2024 April 8 comes out at 0.3437 against a published 0.3431, and the radius ratio reproduces the published magnitude once k = 0.272281 is used — the value adopted for umbral contacts rather than the mean lunar radius, which overstates it by 0.2% and lands squarely on the difference of two nearly equal radii that sets how long totality lasts. Luxor in 2027 comes out at 6m22s against a published 6m20s, and Madrid in 2026 correctly misses totality at 99.95%. Contact times land within about half a minute, which is the floor for a truncated lunar series; totality duration is quoted approximately for the same reason. Two things the eclipse work had to be defensive about in NotificationManager. iOS keeps only 64 pending requests and the daily loop already claimed every one, so the eclipse alerts are budgeted rather than appended. They are also scheduled before that loop, which returns outright on the first day suppressed by the SAD preference and would otherwise skip them silently. The detail section shows any eclipse covering a tenth of the sun or more, with the full treatment — contact times, duration, eye safety — reserved for 90% and above. A 90%-only rule would have left the section dormant for decades at a time; at a tenth, London gets one in 2026, 2027 and 2028. Notifications keep the higher bar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PR3DD68Nh3jRJ6H7z8fHn1
…he icons Design feedback on the eclipse section. The section title only appeared for major eclipses, which read as arbitrary — remove it outright. The section is still self-describing without one, since the first row's label already names the kind of eclipse. The eye-safety footer was conditional in exactly the same way, so it goes the same way for the same reason: staring at a 20% eclipsed sun does the same damage as a 95% one, and the section prompts someone to look up either way. It now shows whenever the section does. The wording still varies by kind, because only a total eclipse has a phase that is safe to view unaided. Between them that leaves isMajor controlling one thing — full rows or the single compact row — rather than three. Icons: the contact rows borrowed sunrise/sunset symbols, which read as times of day rather than as something crossing the sun, so they move to the moon-phase set. The partial-eclipse kind and the maximum-coverage row pick up sun-based symbols in place of the generic circles. The section's presence is now animated. withAnimation sits at the mutation site in findEclipse rather than as .animation(_:value:) on the form, which would have animated unrelated content in the daily and annual sections too. Also drops "Upcoming solar eclipse" and its nine translations from the catalog, now that nothing references it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PR3DD68Nh3jRJ6H7z8fHn1
…dule The 64-day scheduling loop returned rather than continued when buildNotificationContent came back nil. That happens for a single day at a time — either NTSolar failed to construct, or the SAD preference suppressed that day because daylight was shortening — so bailing out of the loop threw away every remaining day too. For anyone with "Suppress notifications" set, that meant the first shortening day cancelled the rest of the schedule. Through the second half of the year in the northern hemisphere that is day zero, so those users got no daily notifications at all for the next 64 days instead of notifications on the days that were actually lengthening. The preference is meant to hold back the dispiriting notifications, not switch the feature off. Not covered by a test: the loop lives inside scheduleNotifications, which resolves a Core Data location and writes to UNUserNotificationCenter, so reaching it would mean extracting the loop body and injecting the notification centre — too much refactoring to hang off a one-word fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PR3DD68Nh3jRJ6H7z8fHn1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Solstice had nothing to say about the most dramatic thing the sun ever does.
This adds a detail-view section for an upcoming solar eclipse visible from a
location, and two local notifications for eclipses that cover most of the sun.
The maths is new ground: NTSolar is sun-only, and eclipse circumstances need
the moon. EclipseCalculator follows the precedent SolsticeCalculator already
sets — a stateless enum holding a Meeus port with its own Julian day helpers —
using chapter 25 for the sun, chapter 47 for the moon and chapter 49 to step
lunation by lunation. Positions are converted to topocentric coordinates,
which is what makes an eclipse a local event at all: the moon's horizontal
parallax is nearly a degree, comparable to the whole geometry involved.
NTSolar is not reused because its solar model neglects aberration and costs
about an arcminute, roughly 6% of eclipse magnitude.
Checked against NASA's published circumstances. Gamma for 2024 April 8 comes
out at 0.3437 against a published 0.3431, and the radius ratio reproduces the
published magnitude once k = 0.272281 is used — the value adopted for umbral
contacts rather than the mean lunar radius, which overstates it by 0.2% and
lands squarely on the difference of two nearly equal radii that sets how long
totality lasts. Luxor in 2027 comes out at 6m22s against a published 6m20s,
and Madrid in 2026 correctly misses totality at 99.95%. Contact times land
within about half a minute, which is the floor for a truncated lunar series;
totality duration is quoted approximately for the same reason.
Two things the eclipse work had to be defensive about in NotificationManager.
iOS keeps only 64 pending requests and the daily loop already claimed every
one, so the eclipse alerts are budgeted rather than appended. They are also
scheduled before that loop, which returns outright on the first day suppressed
by the SAD preference and would otherwise skip them silently.
The detail section shows any eclipse covering a tenth of the sun or more,
with the full treatment — contact times, duration, eye safety — reserved for
90% and above. A 90%-only rule would have left the section dormant for
decades at a time; at a tenth, London gets one in 2026, 2027 and 2028.
Notifications keep the higher bar.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01PR3DD68Nh3jRJ6H7z8fHn1