You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug pvlib.solarposition.sun_rise_set_transit_ephem returns a different answer depending on what version of ephem is installed. I think the problem is that our wrapper assumes that ephem doesn't pay attention to timezone localization, so it converts the timestamp components to UTC but doesn't bother to change the timestamp's tzinfo:
# pyephem drops timezone when converting to its internal datetime
# format, so handle timezone explicitly here
obs.date=ephem.Date(thetime-thetime.utcoffset())
However, starting in ephem==4.1.1 the timezone is no longer ignored (ref), so the UTC offset is applied twice. This can shift the timestamp into the next solar period and return the rise/set/transit for the wrong day.
To Reproduce
See how the returned sunrise differs by ~24 hours (2019-01-01 vs 2019-01-02) here:
Expected behavior
pvlib should give ephem timestamps consistent with its input requirements. Replacing the above manual utc offset subtraction (which leaves the original tzinfo in place) with thetime.astimezone(pytz.UTC) may be suitable for both old and new versions of ephem. I don't ever use pytz and python datetimes so maybe there's a better alternative.
Describe the bug
pvlib.solarposition.sun_rise_set_transit_ephem
returns a different answer depending on what version ofephem
is installed. I think the problem is that our wrapper assumes that ephem doesn't pay attention to timezone localization, so it converts the timestamp components to UTC but doesn't bother to change the timestamp's tzinfo:pvlib-python/pvlib/solarposition.py
Lines 577 to 579 in 8d0f863
However, starting in
ephem==4.1.1
the timezone is no longer ignored (ref), so the UTC offset is applied twice. This can shift the timestamp into the next solar period and return the rise/set/transit for the wrong day.To Reproduce
See how the returned sunrise differs by ~24 hours (2019-01-01 vs 2019-01-02) here:
ephem==4.0.0.1
:ephem==4.1.2
:Expected behavior
pvlib should give ephem timestamps consistent with its input requirements. Replacing the above manual utc offset subtraction (which leaves the original tzinfo in place) with
thetime.astimezone(pytz.UTC)
may be suitable for both old and new versions of ephem. I don't ever use pytz and python datetimes so maybe there's a better alternative.Versions:
pvlib.__version__
: 0.9.1Additional context
This difference would have popped up back in November when ephem 4.1.1 was released had it not been for #1447. Here's an example failure: https://dev.azure.com/solararbiter/pvlib%20python/_build/results?buildId=6027&view=logs&j=e1592cb8-2816-5754-b393-3839a187d454&t=377c4fd6-97bd-5996-bc02-4d072a8786ea&l=2267
The text was updated successfully, but these errors were encountered: