Unexpected behaviour with sun_rise_set_transit_spa

[williamhobbs]

Describe the bug
This may be related to #2238, #2820. For some longitudes pvlib.solarposition.sun_rise_set_transit_spa returns sunrise and sunset times that are on the same day, but for other latitudes longitudes, the sunset time is shifted one day later. I don't think this is expected, but maybe I'm missing something?

I see the same behavior with pvlib 0.15.2 and 0.15.3a1, which I think should include the fix from #2820.

To Reproduce
Steps to reproduce the behavior:

Install latest stable release:

pip install pvlib

then

import pandas as pd
import pvlib
times = pd.date_range("2000-01-01 05:00", "2000-01-02 05:00", freq='1h').tz_localize("UTC")
# try [longitude] of -100
pvlib.solarposition.sun_rise_set_transit_spa(times, 40, -100)[['sunrise', 'sunset']]

...

# try [longitude] of -110
pvlib.solarposition.sun_rise_set_transit_spa(times, 40, -110)[['sunrise', 'sunset']]

Upgrade to latest version:

pip uninstall pvlib -y
pip install git+https://github.com/pvlib/pvlib-python

restart, repeat the first steps with the new version.

Expected behavior
I expect the same behavior for both latitudes longitudes. Not sure if the two versions of pvlib should behave the same.

Screenshots
with latitude of -100:

Note the different date for sunset after changing latitude to -110:

And the same results with 0.15.3a1:

Versions:

• pvlib.__version__: '0.15.2' and '0.15.3a1'
• pandas.__version__: '3.0.2'
• python: 3.13.9

Additional context
Add any other context about the problem here.

[cwhanse]

I can reproduce the issue. Note that the issue says "latitude" several places where you meant "longitude."

I'll gripe a little bit that these sunrise/sunset functions have been trouble enough that I would entertain the idea of simply dropping them, and replacing with a purely geometric calculation.

[williamhobbs]

Note that the issue says "latitude" several places where you meant "longitude."

Thanks, I updated the issue.

I would entertain the idea of simply dropping them, and replacing with a purely geometric calculation.

I'm not sure what the pros and cons would be there, but for some additional context, I only just now started experimenting with sun_rise_set_transit_spa because I'm looking for a solution to this: pvlib/solposx#153.

Not having a way to elegantly/flexibly handle intervals where sunrise/sunset occur, particularly when the sun is below the horizon at the midpoint of the interval, seems like a relatively large gap in pvlib compared to common industry tools. I'm not sure if that feedback is helpful in relation to keeping/dropping these functions...

[williamhobbs]

Edit: I previously posted a "fix" here, but I was misunderstanding things. Don't use what I suggested... (I think you can view the comment history if you are curious...)

[cwhanse]

In the case of spa.transit_sunrise_sunset the code was ported from NREL software, so it retains the behavior of that software, unless pvlib has wandered off trying to fix these day boundary issues.

The SPA calculator behaves similarly to what the pvlib code does now: using latitude 40, longitude -110, it returns a sunset time of 0.0736 (hours) for 1/1/2020. Although sunset time isn't dated, I'm fairly sure its supposed to be after sunrise, so that would be 1/2/2020, same as the current pvlib.

[williamhobbs]

What does the SPA calculator return for 40, -100? Or more specifically, is it consistent with 40, -110?

[cwhanse]

NREL SPA calculator returns sunset at 23.42 hours at 40, -100, and at 0.0736 hours at 40, -110. The calculator only returns times, not full datetimes. Its behavior is the same as pvlib. https://midcdmz.nlr.gov/solpos/spa.html

[williamhobbs]

Thanks.

Maybe the issue should be re-named to “I don’t understand how this function is supported to work” 😅

On a more serious note, maybe the docs need to be updated somehow? Alternatively, feel free to close this if you don’t think there’s anything needed.

[williamhobbs]

Ok, I understand this now. For the second location, sunset is simply ~40 minutes later, so shows up on the next calendar day (UTC time). Not sure why I didn't follow that yesterday. Closing this issue.