[Bug]: Matplotlib date2num timezone removal issue

[DStauffman]

Bug summary

There is a problem if some dates have time zone information and some are just dates and not datetimes. In date2num, only the first occurence in the list is checked, but plain dates cannot be converted. tzi = getattr(d[0], 'tzinfo', None)

Code for reproduction

>> import datetime
>> from matplotlib.dates import date2num

>> date2num([datetime.date(2024, 3, 5), datetime.datetime(2024, 3, 4, tzinfo=datetime.UTC)])
array([19787., 19786.])

>> date2num([datetime.datetime(2024, 3, 4, tzinfo=None), datetime.date(2024, 3, 5)])
array([19786., 19787.])

>> date2num([datetime.datetime(2024, 3, 4, tzinfo=datetime.UTC), datetime.date(2024, 3, 5)])
# Expected array([19787., 197876.]), got error instead

### Actual outcome

File ...\Lib\site-packages\matplotlib\dates.py:459 in date2num
d = [dt.astimezone(UTC).replace(tzinfo=None) for dt in d]

File ...\Lib\site-packages\matplotlib\dates.py:459 in
d = [dt.astimezone(UTC).replace(tzinfo=None) for dt in d]

AttributeError: 'datetime.date' object has no attribute 'astimezone'

### Expected outcome

Expected `array([19787., 197876.])`

### Additional information

Not sure if this is a valid use case or not, but the bug is triggered if the first item in the list is time zone aware, and then any other item is just a datetime.date and not a datetime.datetime

### Operating system

Windows 10

### Matplotlib Version

3.8.2

### Matplotlib Backend

QtAgg

### Python version

3.11.5

### Jupyter version

_No response_

### Installation

pip

[jklymak]

All your dates are going to have to have the same time zone info. Perhaps the documentation could be clearer, but mixing types or units in a single call to a plotting function is not garanties to work.

[ksunden]

This code was introduced in #18756, and was made with performance reasons in mind...

The intent is that if you don't have tz info then you don't need to loop over everything (and even looking to see if you would need to is looping over every element...) So yes, most of our Units-related code works on the assumption that you have a homogeneous unit, even if the units are held on the individual entry not the container...

Technically, numpy does what we want at present... (and this whole loop is not necessary...) however that behavior is deprecated in numpy and will start warning with the 2.0 release (and be removed later)... so we absolutely cannot rely on that, unfortunately...

Once numpy starts actually erroring, the first example here (where there is no tz for element 0, but is for element 1) would actually break...