incorrect results for Observer rise transit set methods

[Jim Netter]

specifically, for the moon:
>>> here = city('Chicago')
>>> mo = Moon(here)
>>> print here.date
2011/9/28 15:37:59
>>> print here.previous_rising(mo)
2011/9/28 13:16:51
>>> print here.previous_transit(mo)
2011/9/27 17:48:39
>>> print here.previous_setting(mo)
2011/9/26 22:55:34
>>> print here.next_rising(mo)
2011/9/28 13:16:51
>>> print here.next_transit(mo)
2011/9/28 18:44:54
>>> print here.next_setting(mo)
2011/9/29 00:04:11

previous and next rising are the same. previous and next setting skip a setting.
for myself, treating each rise, set and transit as a unit would make coding easier. that is, previous rise is the most recent rise event, and previous transit and set are its successive transit and set events, regardless of their relation to observer.date.

[Jim Netter (netter-j)]

These could work like next_passing, returning a 6 part tuple (or a circumpolar or never rises error)

[Brandon Rhodes (brandon-rhodes)]

It should be easy to write a small function of your own that returns such a tuple — I can put together an example for you by the end of this weekend and I will post it here in the bug comments.

But the larger issue here is that you are getting confused by XEphem's behavior, and for a *very* good reason: the behavior of the "transit()" functions is completely inconsistent with the behavior of the rising/setting functions! In particular, it looks like rising and setting functions do *not* actually change the .date of your city object; but the transit functions *do* leave the .date at a changed value — the value they also return as the transit time.

So I will look into making the behavior more consistent in the next release, if I think I can do that without breaking lots of old code that people have written — and I will post my decision here on this bug. Meanwhile, you can avoid the "skipping" behavior you are seeing by setting "here.date" back to its original value when you are done with a "transit()" call.

Thanks for pointing this problem out!

[Jim Netter (netter-j)]

I'm working now on a moon function that returns a 12 element tuple of previous-or-current rts data and next rts data with an observer as function argument. That is, if the moon is up at observer time, it's current and next, and if the moon is down, it's previous and next. It's looking rather cumbersome (I'm an enthusiastic but not expert python guy), but I think it's working properly. It uses the (deprecated) Moon() calls to rise_time, rise_az, etc.

Given your explanation about XEphem's transit v. rise/set behavior, I'll look at what I have and see if I can simplify my routine by going back to the Observer methods. Thanks a lot for the clarification!

As a general consideration, I think that a function that returns rts as a sequential unit is best for geocentric orbital bodies, including the moon. Just makes sense to me.

Thanks again for continuing development on this project!

[Brandon Rhodes (brandon-rhodes)]

I have adjusted the transit functions so that they stop changing the value of the Observer they have been passed; this makes it easy for users to build a sequence of rise/transit/set calls that should return a series of events that happen on a single day. Thanks for pointing out the problem, and version 3.7.5.1 with this fix should come out this evening!