mirror of
https://github.com/AvengeMedia/DankMaterialShell.git
synced 2026-10-14 07:14:00 -04:00
* fix(theme): take sun times from the local calendar day, not the UTC one CalculateSunTimesWithTwilight read its reference day off date.UTC(). The event seconds it computes are local mean solar time and lonOffset converts them to UTC, so the instant of a local day's sunrise lands on the previous UTC day east of Greenwich and a local sunset on the next one west of it. Whenever the local and UTC calendars disagree, the function therefore returned a neighbouring day's times. Everything around it already works in local calendar days: the polar branches of CalculateSunTimes build their day from date.Year/Month/Day, thememode's startOfNextDay uses next.Location(), and the gamma scheduler keys its calcDay cache on now.Location(). Only the reference day inside the calculation disagreed. Effect at UTC+8 (Kunming, 25.04N 102.72E): between local sunrise and 08:00 local, computeLocationSchedule got yesterday's sunrise and sunset, both already past, fell through to the next-day branch and got today's sunrise, also past. It reported dark with nextTransition in the past, which schedulerLoop clamps to a one-second wait, so it re-evaluated every second until 08:00 local and then flipped to light on its own. West of UTC the mirror image: at UTC-7 the mode went dark from 17:00 local, when the UTC date rolls over, until the real sunset. The same SunTimes drive the gamma/night-light scheduler, so night light shifted by a day the same way. Fix: derive the reference day from date's own calendar day, keeping dayStart anchored at UTC midnight so the lonOffset arithmetic is unchanged, and take the orbit angle from the same day. Callers whose date is already in UTC are unaffected. Tests: suncalc_refday_test.go covers the reference day east and west of UTC, stability across UTC midnight, and that UTC callers do not move. manager_location_test.go is new to the thememode package and covers computeLocationSchedule at both offsets, including that nextTransition is never in the past. * fix(theme): pick the reference day from the solar day, not the civil one Taking the reference day straight off the caller's calendar day is right for nearly every zone, but not for one shifted a full day away from its own meridian. Apia, Kiritimati, Tongatapu and the Chathams all sit on west longitudes while keeping a UTC+12:45..+14 offset, so their mean solar time and their civil time are a day apart. Every sun event landed on the following local day there, and the location schedule reported dark around the clock. Anchor on the caller's local noon and convert that to mean solar time to pick the reference day. For every other zone this resolves to the same date as before, so Kunming, Los Angeles and London are unchanged to the second. dateOrbitAngle now takes the same reference day, so declination and the equation of time no longer belong to a different day than the events computed from them. Covered at both levels: three antimeridian zones in the suncalc test, and two cases in the location schedule test for the symptom itself. Both fail without this change.