Moonrise appears to be nil on certain day, on certain place

[vincentneo]

Yet again apologies for opening yet another issue:

This time round it's from a user's complain about missing moonrise time in my app that utilises this library. Apparently on certain day, on certain place, the rise time will go nil.

Specifically, the user said that it occurs in Orefield, PA, US on 4 October 2020. (or 3 depending on timezone), so I checked the response from a piece of code, testing from 3 Oct to 5 Oct:

        let jd = JulianDay(year: 2020, month: 10, day: 04)
        let location = GeographicCoordinates(CLLocation(latitude: 40.635, longitude: -75.584))
        let times = RiseTransitSetTimes(celestialBody: Moon(julianDay: jd), geographicCoordinates: location)
        
        let formatter = DateFormatter()
        formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZ"
        formatter.timeZone = TimeZone(abbreviation: "UTC")

        let rise = times.riseTime != nil ? formatter.string(from: times.riseTime!.date) : "nil"
        let transit = times.transitTime != nil ? formatter.string(from: times.transitTime!.date) : "nil"
        let set = times.setTime != nil ? formatter.string(from: times.setTime!.date) : "nil"
        
        print(rise) // nil if day is 04
        print(transit)
        print(set)

and sure enough, 4 Oct has its rise date nil, but 3/5 Oct has results for all three.

I've checked multiple sources:
https://www.timeanddate.com/moon/@z-us-18069
https://www.almanac.com/astronomy/moon-rise-and-set/zipcode/18069/2020-10-04

And it does appear that moon rise time should be valid at that place at that time, so I reckon something's wrong somewhere?

Thank you for taking the time reading this.

[tallPete]

I also use this library for Moon rise and set times in my app and I do get the correct range of times for Orefield, PA, so they are in there. I don't get any nil values. I haven't run the test code above, but I am commenting as I would be scared if a random change to the library is committed that says subtract or add one day in certain situations - it will affect other users. There are many situations to consider in moon rise and set times - including set times before rise times, no transit or underfoot on particular days, no rise or set on particular days. There are many folk who use SwiftAA/AAPlus.

[vincentneo]

scared if a random change to the library is committed that says subtract or add one day in certain situations

I think you’re mixing up with pr #100. That has nothing to do with this issue. pr #100 simply ensures that the correct date is given out, for certain regions as current code meant that if rise/set overlaps to another day, it will return with the original day, not accounting for the overlap. (E.g if sunset is 1am of the next day according to UTC time)

Calculations were not touched whatsoever. Just the date return part, which if you look at the code, is not computed.

As for opening this issue, it is just for the fact that I am reporting something that I did not expect. It’s just observable for one day, so it could be my error, but it could also be something else.

[onekiloparsec]

@tallPete

There are many folk who use SwiftAA/AAPlus
I'd love to head about them, to include their app inside the README links ! Don't hesitate to spread the word.

@vincentneo I'll check that thing for the Moon, indeed.

[vincentneo]

I'd love to head about them, to include their app inside the README links ! Don't hesitate to spread the word.

@onekiloparsec Hope you don't mind me shamelessly advertising it here 😅:
Sunlight - Rise & Set Times https://apple.co/36OZLlx

[vincentneo]

@onekiloparsec
I'll be closing this.

Upon investigating and, through also bringing CAARiseTransitSet2 of AA+ (which I noticed is absent in SwiftAA) to Swift (on my branch https://github.com/vincentneo/SwiftAA/tree/sl)

I assume that it happens, where rise time was nil on that day because it was of the previous day and hence was not considered as that day.

Regardless, I think the CAARiseTransitSet2 implementation of recent AA+ releases make things better by having a start and end Julian day, with returns of a Julian Day too.

I never had any formal education of C++ or Objective-C however, so my port from my branch might be rough (or even broken without knowing it myself), but do take a look into that code. If any part looks good enough for a pull request, but require refactoring, feel free to tell me what to do.

[onekiloparsec]

If you don't mind, I'll reopen the issue, for me to check and work on that CAARiseTransitSet2 new implementation. I didn't know it existed. Of course, SwiftAA must also benefit from advances in AA+.

[vincentneo]

There appears to be a couple of new v2 implementations over at AA+, actually,

• AAEquinoxesAndSolstices2
• AAMoonMaxDeclinations2
• AAMoonPhases2
  ...
  to name a few

[onekiloparsec]

Just a little note saying I haven't forget. Just too busy with new job... But I'll eventually get there !

[onekiloparsec]

I relase I am late in the game. I will update SwiftAA to adopt the new v2 classes.