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
Is your feature request related to a problem? Please describe.
I am looking into replacing pytz with the standard library's zoneinfo, and I found three untested functions that use pytz:
pvlib.tools.localize_to_utc
pvlib.tools.datetime_to_djd
pvlib.tools.djd_to_datetime
Describe the solution you'd like
Add tests for these three functions before attempting to replace pytz in a refactor.
Describe alternatives you've considered
Adding tests should be a welcome endeavor, no matter if pytz is replaced or not.
Additional context
None.
UPDATE: #2341 that addresses this issue moves to the Python 3.9+ standard library's zoneinfo.ZoneInfo as the single source of truth that represents a timezone internally in Location objects. Also, the interface to this object was made consistent between the Location intializer and updating the tz string attribute after object initialization (and tz is now always a string, as previous advertised). However, Location objects still all existing types for initializing tz, as well as still exposing a pytz representation of the Location's timezone as the read-only pytz attribute.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I am looking into replacing
pytz
with the standard library'szoneinfo
, and I found three untested functions that usepytz
:Describe the solution you'd like
Add tests for these three functions before attempting to replace
pytz
in a refactor.Describe alternatives you've considered
Adding tests should be a welcome endeavor, no matter if
pytz
is replaced or not.Additional context
None.
UPDATE: #2341 that addresses this issue moves to the Python 3.9+ standard library's
zoneinfo.ZoneInfo
as the single source of truth that represents a timezone internally inLocation
objects. Also, the interface to this object was made consistent between theLocation
intializer and updating thetz
string attribute after object initialization (andtz
is now always a string, as previous advertised). However,Location
objects still all existing types for initializingtz
, as well as still exposing apytz
representation of the Location's timezone as the read-onlypytz
attribute.The text was updated successfully, but these errors were encountered: