move src/datetime.pxd funcs to np_datetime and fix misleading names

[jbrockmendel]

The name _pydatetime_to_dts is misleading, since dts is the variable names used for pandas_datetimestruct objects, while the func actually returns an int64. This renames it to _pydatetime_to_dt64.

The analogous function for datetime.date has the non-misleading name _date_to_datetime64. For consistency this is renamed to _pydate_to_dt64.

Both are moved to np_datetime, and have their inputs typed as datetime and date instead of object.

[codecov]

Codecov Report

Merging #18045 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #18045      +/-   ##
==========================================
- Coverage   91.24%   91.23%   -0.02%     
==========================================
  Files         163      163              
  Lines       50114    50114              
==========================================
- Hits        45729    45720       -9     
- Misses       4385     4394       +9

Flag	Coverage Δ
#multiple	89.04% <ø> (ø)	⬆️
#single	40.24% <ø> (-0.06%)	⬇️

Impacted Files	Coverage Δ
pandas/io/gbq.py	25% <0%> (-58.34%)	⬇️
pandas/core/frame.py	97.75% <0%> (-0.1%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c65a0f5...075574d. Read the comment docs.

[codecov]

Codecov Report

Merging #18045 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #18045      +/-   ##
==========================================
- Coverage   91.24%   91.23%   -0.02%     
==========================================
  Files         163      163              
  Lines       50114    50114              
==========================================
- Hits        45729    45720       -9     
- Misses       4385     4394       +9

Flag	Coverage Δ
#multiple	89.04% <ø> (ø)	⬆️
#single	40.24% <ø> (-0.06%)	⬇️

Impacted Files	Coverage Δ
pandas/io/gbq.py	25% <0%> (-58.34%)	⬇️
pandas/core/frame.py	97.75% <0%> (-0.1%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c65a0f5...ccf793e. Read the comment docs.

[jreback]

I would de-privatize

[jbrockmendel]

taskset 3 asv continuous -E virtualenv -f 1.1 master HEAD -b timeseries
[...]
       before           after         ratio
     [4578a039]       [075574d7]
+           1.61s            1.95s     1.22  timeseries.AsOfDataFrame.time_asof_nan
+        124±20ms            145ms     1.17  timeseries.DatetimeIndex.time_dti_tz_factorize
-      21.6±0.2μs       19.3±0.1μs     0.89  timeseries.Offsets.time_custom_bday_incr
-      27.1±0.2μs       23.9±0.1μs     0.88  timeseries.Offsets.time_custom_bday_cal_incr
-           1.89s            1.66s     0.88  timeseries.AsOfDataFrame.time_asof
-       149±0.2ms        130±0.1ms     0.88  timeseries.ToDatetime.time_iso8601_tz_spaceformat
-      17.6±0.1μs       14.7±0.1μs     0.83  timeseries.Offsets.time_custom_bday_apply
-        14.4±1ms      11.8±0.01ms     0.82  timeseries.DatetimeIndex.time_infer_freq_none
-        21.0±2ms         11.8±1ms     0.56  timeseries.TimeSeries.time_add_irregular

Any idea why time_asof_nan and time_dti_tz_factorize might slow down? There should be small bumps from specifying types for pydate_to_dt64 and pydatetime_to_dt64, and from cimporting tz_convert_single in offsets. The only drag I can think of is maybe having funcs in a .pyx instead of .pxd affects how they are inlined?

[jreback]

I benchmarked this and it showed very little changes (as expected). something is still going on with your asv. you should always use affinity.

[jbrockmendel]

Thanks for double-checking.