Merge branch 'main' into pr/2775

Author: AdamRJensen

docs/examples/irradiance-transposition/plot_rtranpose_limitations.py

@@ -28,7 +28,7 @@
 #
 # In this example we look at a single point in time and consider a full range
 # of possible GHI and POA global values as shown in figures 3 and 4 of [1]_.
-# Then we use :py:meth:`pvlib.irradiance.ghi_from_poa_driesse_2023` to estimate
+# Then we use :py:meth:`pvlib.irradiance.ghi_from_poa_driesse_2024` to estimate
 # the original GHI from POA global.
 #
 # References
@@ -45,7 +45,7 @@
 
 from pvlib.irradiance import (erbs_driesse,
                               get_total_irradiance,
-                              ghi_from_poa_driesse_2023,
+                              ghi_from_poa_driesse_2024,
                               )
 
 matplotlib.rcParams['axes.grid'] = True
@@ -92,7 +92,7 @@
 
 poa_test = 200
 
-ghi_hat = ghi_from_poa_driesse_2023(surface_tilt, surface_azimuth,
+ghi_hat = ghi_from_poa_driesse_2024(surface_tilt, surface_azimuth,
                                     solar_zenith, solar_azimuth,
                                     poa_test,
                                     dni_extra,
@@ -156,7 +156,7 @@
 # out, other times not.
 #
 
-result = ghi_from_poa_driesse_2023(surface_tilt, surface_azimuth,
+result = ghi_from_poa_driesse_2024(surface_tilt, surface_azimuth,
                                    solar_zenith, solar_azimuth,
                                    poa_global,
                                    dni_extra,

docs/examples/irradiance-transposition/plot_rtranpose_year.py

@@ -21,7 +21,7 @@
 # Recovering GHI from POA irradiance is termed "reverse transposition."
 #
 # In this example we start with a TMY file and calculate POA global irradiance.
-# Then we use :py:meth:`pvlib.irradiance.ghi_from_poa_driesse_2023` to estimate
+# Then we use :py:meth:`pvlib.irradiance.ghi_from_poa_driesse_2024` to estimate
 # the original GHI from POA global.  Details of the method found in [1]_.
 #
 # Another method for reverse tranposition called GTI-DIRINT is also
@@ -49,7 +49,7 @@
 from pvlib import iotools, location
 from pvlib.irradiance import (get_extra_radiation,
                               get_total_irradiance,
-                              ghi_from_poa_driesse_2023,
+                              ghi_from_poa_driesse_2024,
                               aoi,
                               )
 
@@ -114,7 +114,7 @@
 
 start = time.process_time()
 
-df['ghi_rev'] = ghi_from_poa_driesse_2023(TILT, ORIENT,
+df['ghi_rev'] = ghi_from_poa_driesse_2024(TILT, ORIENT,
                                           solpos.apparent_zenith,
                                           solpos.azimuth,
                                           df.poa_global,

docs/sphinx/source/reference/irradiance/reverse-transposition.rst

@@ -6,5 +6,5 @@ Reverse transposition models
 .. autosummary::
    :toctree: ../generated/
 
-   irradiance.ghi_from_poa_driesse_2023
+   irradiance.ghi_from_poa_driesse_2024
    irradiance.gti_dirint

docs/sphinx/source/user_guide/modeling_topics/timetimezones.rst

@@ -5,7 +5,7 @@ Time and time zones
 
 Dealing with time and time zones can be a frustrating experience in any
 programming language and for any application. pvlib-python relies on
-:py:mod:`pandas` and `pytz <http://pythonhosted.org/pytz/>`_ to handle
+:py:mod:`pandas` and the builtin :py:mod:`python:zoneinfo` to handle
 time and time zones. Therefore, the vast majority of the information in
 this document applies to any time series analysis using pandas and is
 not specific to pvlib-python.
@@ -14,52 +14,53 @@ General functionality
 ---------------------
 
 pvlib makes extensive use of pandas due to its excellent time series
-functionality. Take the time to become familiar with pandas' `Time
-Series / Date functionality page
-<http://pandas.pydata.org/pandas-docs/version/0.18.0/timeseries.html>`_.
+functionality. Take the time to become familiar with pandas'
+:external+pandas:doc:`Time Series / Date functionality page <user_guide/timeseries>`.
 It is also worthwhile to become familiar with pure Python's
-:py:mod:`python:datetime` module, although we usually recommend
-using the corresponding pandas functionality where possible.
+:py:mod:`python:datetime` module, although we usually recommend using the
+corresponding pandas functionality where possible.
 
 First, we'll import the libraries that we'll use to explore the basic
 time and time zone functionality in python and pvlib.
 
 .. ipython:: python
 
     import datetime
+    import zoneinfo
     import pandas as pd
-    import pytz
 
 
 Finding a time zone
 *******************
 
-pytz is based on the Olson time zone database. You can obtain a list of
-all valid time zone strings with ``pytz.all_timezones``. It's a long
-list, so we only print every 20th time zone.
+``zoneinfo`` is based on the IANA (Olson) time zone database. You can obtain
+a set of all valid time zone strings with ``zoneinfo.available_timezones()``.
+It's a large set, so we only print every 20th time zone (sorted for
+consistency).
 
 .. ipython:: python
 
-    len(pytz.all_timezones)
-    pytz.all_timezones[::20]
+    len(zoneinfo.available_timezones())
+    sorted(zoneinfo.available_timezones())[::20]
 
 Wikipedia's `List of tz database time zones
 <https://en.wikipedia.org/wiki/List_of_tz_database_time_zones>`_ is also
 good reference.
 
-The ``pytz.country_timezones`` function is useful, too.
+You can filter the available time zones using Python's built-in
+:py:func:`python:filter` function.
 
 .. ipython:: python
 
-    pytz.country_timezones('US')
+    sorted(filter(lambda x: 'America' in x, zoneinfo.available_timezones()))
 
-And don't forget about Python's :py:func:`python:filter` function.
+And you can also filter for GMT-based fixed offset zones:
 
 .. ipython:: python
 
-    list(filter(lambda x: 'GMT' in x, pytz.all_timezones))
+    sorted(filter(lambda x: 'GMT' in x, zoneinfo.available_timezones()))
 
-Note that while pytz has ``'EST'`` and ``'MST'``, it does not have
+Note that while the IANA database has ``'EST'`` and ``'MST'``, it does not have
 ``'PST'``. Use ``'Etc/GMT+8'`` instead, or see :ref:`fixedoffsets`.
 
 Timestamps
@@ -125,7 +126,7 @@ vs. the UTC offset in summer...
     pd.Timestamp('2015-6-1 00:00').tz_localize('US/Mountain')
     pd.Timestamp('2015-6-1 00:00').tz_localize('Etc/GMT+7')
 
-pandas and pytz make this time zone handling possible because pandas
+pandas makes this time zone handling possible because pandas
 stores all times as integer nanoseconds since January 1, 1970.
 Here is the pandas time representation of the integers 1 and 1e9.
 
@@ -174,12 +175,13 @@ specifications, but watch out for the counter-intuitive sign convention.
 
     pd.Timestamp('2015-1-1 00:00', tz='Etc/GMT-2')
 
-Fixed offset time zones can also be specified as offset minutes
-from UTC using ``pytz.FixedOffset``.
+Fixed offset time zones can also be specified using
+:py:class:`python:datetime.timezone` with a
+:py:class:`python:datetime.timedelta` offset.
 
 .. ipython:: python
 
-    pd.Timestamp('2015-1-1 00:00', tz=pytz.FixedOffset(120))
+    pd.Timestamp('2015-1-1 00:00', tz=datetime.timezone(datetime.timedelta(hours=2)))
 
 You can also specify the fixed offset directly in the ``tz_localize``
 method, however, be aware that this is not documented and that the
@@ -216,8 +218,8 @@ expected.
     # tz naive pandas Timestamp object
     pd.Timestamp(naive_python_dt)
 
-    # tz aware python datetime.datetime object
-    aware_python_dt = pytz.timezone('US/Mountain').localize(naive_python_dt)
+    # tz aware python datetime.datetime object using zoneinfo
+    aware_python_dt = naive_python_dt.replace(tzinfo=zoneinfo.ZoneInfo('US/Mountain'))
 
     # tz aware pandas Timestamp object
     pd.Timestamp(aware_python_dt)
@@ -234,13 +236,14 @@ passed to ``Timestamp``.
     # tz naive pandas Timestamp object (time=midnight)
     pd.Timestamp(naive_python_date)
 
-You cannot localize a native Python date object.
+You cannot localize a native Python date object directly; you must first
+convert it to a :py:class:`python:datetime.datetime`.
 
 .. ipython:: python
    :okexcept:
 
-    # fail
-    pytz.timezone('US/Mountain').localize(naive_python_date)
+    # fail: datetime.date has no tzinfo support via replace
+    naive_python_date.replace(tzinfo=zoneinfo.ZoneInfo('US/Mountain'))
 
 
 pvlib-specific functionality
@@ -348,7 +351,7 @@ UTC, and then convert it to the desired time zone.
 
 .. ipython:: python
 
-    fixed_tz = pytz.FixedOffset(tmy3_metadata['TZ'] * 60)
+    fixed_tz = datetime.timezone(datetime.timedelta(hours=tmy3_metadata['TZ']))
     solar_position_hack = solar_position_notz.tz_localize('UTC').tz_convert(fixed_tz)
 
     solar_position_hack.index

docs/sphinx/source/whatsnew.rst

@@ -6,6 +6,7 @@ What's New
 
 These are new features and improvements of note in each release.
 
+.. include:: whatsnew/v0.15.3.rst
 .. include:: whatsnew/v0.15.2.rst
 .. include:: whatsnew/v0.15.1.rst
 .. include:: whatsnew/v0.15.0.rst

docs/sphinx/source/whatsnew/v0.15.2.rst

@@ -1,73 +1,86 @@
 .. _whatsnew_0_15_2:
 
 
-v0.15.2 (Anticipated June 2026)
--------------------------------
-
-Breaking Changes
-~~~~~~~~~~~~~~~~
+v0.15.2 (June 16, 2026)
+-----------------------
 
 
 Deprecations
 ~~~~~~~~~~~~
+* Deprecate :py:attr:`pvlib.location.Location.pytz`.
+  Use :py:attr:`~pvlib.location.Location.tz` instead. (:issue:`2343`, :pull:`2757`)
+* Rename :py:func:`!pvlib.irradiance.ghi_from_poa_driesse_2023` to
+  :py:func:`~pvlib.irradiance.ghi_from_poa_driesse_2024`. The year now reflects
+  the publication date. The old name will be removed in v0.17.0.
+  (:issue:`2774`, :pull:`2777`)
 
 
 Bug fixes
 ~~~~~~~~~
-* Corrects a bug in :py:func:`pvlib.temperature.fuentes`. If inputs were
-  data type integer, users can expect modeled cell temperature values to
-  increase slightly.
-  (:issue:`2608`, :pull:`2745`)
-* Fixes a regression in :py:func:`pvlib.tracking.calc_surface_orientation`
+* Fix :py:func:`pvlib.temperature.fuentes` truncating the output if `poa_global` input was
+  data type integer. Users can expect modeled cell temperature values to
+  increase slightly. (:issue:`2608`, :pull:`2745`)
+* Fix a regression in :py:func:`pvlib.tracking.calc_surface_orientation`
   introduced in v0.15.1 (:pull:`2702`) that caused a broadcasting
   ``ValueError`` when ``tracker_theta`` was a 2-D (or higher rank) array.
   (:issue:`2747`, :pull:`2749`)
 * Document that timestamps returned by :py:func:`~pvlib.iotools.get_era5`
   represent the end of the averaging interval, consistent with ERA5
   conventions. (:issue:`2772`, :pull:`2773`)
+* Fix header parsing in :py:func:`pvlib.iotools.read_nsrdb_psm4` with quoted
+  commas in column names. This allows spectral-on-demand files to be read. (:issue:`2736`, :pull:`2771`)
+* Update :py:func:`~pvlib.iotools.get_meteonorm_tmy` to comply
+  with the updated Meteonorm API.  As part of this, the ``data_version``
+  parameter now has no effect and will be removed in the future. (:pull:`2781`)
 
 
 Enhancements
 ~~~~~~~~~~~~
 * Add the ``front_side_fraction`` parameter to
   :py:func:`pvlib.snow.loss_townsend` to support Townsend snow-loss
   workflows for bifacial systems. (:issue:`2755`, :pull:`2756`)
-  
-* Added mapping of the parameter ``"albedo"`` in
-  :py:func:`~pvlib.iotools.get_nasa_power` when ``map_variables=True``
-  (:pull:`2753`)
+* Add the following parameters to :py:func:`~pvlib.iotools.get_nasa_power`
+  when ``map_variables=True``: ``temp_dew``, ``precipitable_water``,
+  ``relative_humidity``, ``ghi_extra``, ``dhi_clear``, ``longwave_down``,
+  and ``albedo``. (:issue:`2731`, :pull:`2753`, :pull:`2762`)
 
 
 Documentation
 ~~~~~~~~~~~~~
-* Clarifies that :py:func:`pvlib.soiling.hsu` has an implicit minimum
+* Clarify that :py:func:`pvlib.soiling.hsu` has an implicit minimum
   soiling ratio of approximately 0.6563 due to the mathematical form
   of the model. (:issue:`2534`, :pull:`2743`)
-* Clarifies how Linke turbidity values can be provided to
- :py:func:`pvlib.clearsky.ineichen` via
- :py:func:`pvlib.clearsky.lookup_linke_turbidity` (:issue:`2598`, :pull:`2746`)
+* Clarify how Linke turbidity values can be provided to
+  :py:func:`pvlib.clearsky.ineichen` via
+  :py:func:`pvlib.clearsky.lookup_linke_turbidity`. (:issue:`2598`, :pull:`2746`)
 
 
 Testing
 ~~~~~~~
-
-
-Benchmarking
-~~~~~~~~~~~~
-
-
-Requirements
-~~~~~~~~~~~~
-
-
-Maintenance
-~~~~~~~~~~~
+* Add test coverage for :py:func:`pvlib.irradiance.dirint` with
+  ``np.array`` and ``pd.Series`` inputs. (:issue:`2751`, :pull:`2752`)
 
 
 Contributors
 ~~~~~~~~~~~~
 * :ghuser:`Omesh37`
+* :ghuser:`gaoflow`
 * Cliff Hansen (:ghuser:`cwhanse`)
 * :ghuser:`shethkajal7`
 * Arthur Onno (:ghuser:`ArthurOnnoTerabase`)
 * Adam R. Jensen (:ghuser:`AdamRJensen`)
+* :ghuser:`JoLo90`
+* Karl Hill (:ghuser:`karlhillx`)
+* Rajiv Daxini (:ghuser:`RDaxini`)
+* Vincent Filter (:ghuser:`vfilter`)
+* Klaus Jäger (:ghuser:`solartube`)
+* Carolina Crespo (:ghuser:`cbcrespo`)
+* Ioannis Sifnaios (:ghuser:`IoannisSifnaios`)
+* Anton Driesse (:ghuser:`adriesse`)
+* Mark Mikofski (:ghuser:`mikofski`)
+* Rodrigo Amaro e Silva (:ghuser:`ramaroesilva`)
+* Will Hobbs (:ghuser:`williamhobbs`)
+* Echedey Luis (:ghuser:`echedey-ls`)
+* Cliff Hansen (:ghuser:`cwhanse`)
+* Will Holmgren (:ghuser:`wholmgren`)
+* Kevin Anderson (:ghuser:`kandersolar`)

docs/sphinx/source/whatsnew/v0.15.3.rst

@@ -0,0 +1,45 @@
+.. _whatsnew_0_15_3:
+
+
+v0.15.3 (Anticipated September, 2026)
+-------------------------------------
+
+Breaking Changes
+~~~~~~~~~~~~~~~~
+
+
+Deprecations
+~~~~~~~~~~~~
+
+
+Bug fixes
+~~~~~~~~~
+
+
+Enhancements
+~~~~~~~~~~~~
+
+
+Documentation
+~~~~~~~~~~~~~
+
+
+Testing
+~~~~~~~
+
+
+Benchmarking
+~~~~~~~~~~~~
+
+
+Requirements
+~~~~~~~~~~~~
+
+
+Maintenance
+~~~~~~~~~~~
+
+
+Contributors
+~~~~~~~~~~~~
+

docs/tutorials/solarposition.ipynb

@@ -121,7 +121,7 @@
    "outputs": [],
    "source": [
     "times = pd.date_range(start=datetime.datetime(2014,6,23), end=datetime.datetime(2014,6,24), freq='1Min')\n",
-    "times_loc = times.tz_localize(tus.pytz)"
+    "times_loc = times.tz_localize(tus.tz)"
    ]
   },
   {