-
-
Notifications
You must be signed in to change notification settings - Fork 32
Description
Missing bTransitValid Flag in SwiftAA Transit Calculations
While developing astronomical calculations for our iOS app, I discovered a discrepancy in how SwiftAA handles transit times when the underlying AA+ library indicates no valid transit exists for a requested day.
The root cause is in the data flow between AA+ and SwiftAA. In AA+, the RiseTransitSet calculation (AARiseTransitSet.cpp, lines 214-215) sets a flag called bTransitValid to false when the M0 parameter falls outside the valid range of [0, 1]. This happens when the actual transit time occurs before or after the 24-hour UTC day window. When bTransitValid is false, AA+ returns Transit = 0 (line 264), which represents midnight as a fallback value.
However, when this result is mapped through the AABridge layer (KPCAARiseTransitSet.cpp around line 28), the bTransitValid flag is not included in the PCAARiseTransitSetDetails struct. The struct only contain
60AC
s isRiseValid, isTransitAboveHorizon, and isSetValid - but not ### isTransitValid. This means the critical information that the transit value is actually invalid gets lost during the mapping from AA+ to Swift. The consequence is that SwiftAA receives Transit = 0 (midnight) along with isTransitAboveHorizon = true, and has no way to know that this midnight value is actually a fallback for an invalid transit rather than a real transit at midnight. The SwiftAA layer (RiseTransitSet.swift, lines 188-190) therefore returns a JulianDay object for midnight instead of returning nil as it should. I encountered this issue at my location (Central European Time, GMT+1) when checking the moon transit for November 6, 2025. The actual transit occurred at 23:25 GMT on November 5th, which belongs to the previous GMT day. When calculating for November 6th, AA+ correctly determined that no transit occurs within that UTC day (M0 was approximately -0.027) and set bTransitValid = false. But since this flag doesn't make it through to SwiftAA, my app received midnight (00:00:00 GMT) as the transit time.
After applying ΔT correction (+69 seconds) and timezone conversion (+1 hour), this appeared to the user as 01:01:09 on November 6th - a completely incorrect transit time. The expected behavior would be for SwiftAA to return nil for transitTime when AA+ indicates bTransitValid = false, similar to how rise and set times properly return nil when their respective validity flags are false. I believe the fix would be to add isTransitValid to the KPCAARiseTransitSetDetails struct in the AABridge layer and map it from detailsPlus.bTransitValid, just like isRiseValid and isSetValid are already being mapped. Then SwiftAA could check this flag along with isTransitAboveHorizon before returning a transit time.
As a workaround in my app, I detect when SwiftAA returns exactly midnight by comparing the transit JulianDay with julianDay.midnight, and if they match within 1 second tolerance, I treat it as nil and search adjacent days for the real transit that belongs to the requested local day. I wanted to report this because it seems like an unintended loss of information during the AA+ to Swift mapping, and adding the isTransitValid flag would make SwiftAA's behavior more consistent with AA+'s intent for these edge cases where celestial objects don't transit within a 24-hour UTC day.