standardize post-call treatment of get_dst_info, delay sorting calls

[jbrockmendel]

@jreback we discussed how there are a bunch of functions that do really similar things with get_dst_info but have their slight idiosyncrasies. This standardizes them, and is really verbose so as to delay certain calls until absolutely necessary.

After this we can see about de-duplicating the 6ish occurrences of really similar code by passing a function pointer or something.

[codecov]

Codecov Report

Merging #21960 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #21960   +/-   ##
=======================================
  Coverage   91.96%   91.96%           
=======================================
  Files         166      166           
  Lines       50329    50329           
=======================================
  Hits        46287    46287           
  Misses       4042     4042

Flag	Coverage Δ
#multiple	90.36% <ø> (ø)	⬆️
#single	42.23% <ø> (ø)	⬆️

---

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 3cb64bd...76e0c08. Read the comment docs.

[jreback]

maybe an AssertionError for paths that are not hit (or can just use an assert)

[jreback]

looks fine. is there any perf diff?

[jbrockmendel]

is there any perf diff?

It should be a very small improvement (I'll run asv after the current batch is done, but we know it'll be swamped by noise). The main difference is that calls to trans.searchsorted are avoided in a few cases where we know len(deltas) == 1

[jbrockmendel]

Noise, but at least good noise I guess.

asv continuous -f 1.1 -E virtualenv master HEAD -b timeseries
[...]
       before           after         ratio
     [3cb64bd2]       [76e0c080]
-     3.92±0.03μs      3.55±0.01μs     0.91  timeseries.DatetimeIndex.time_get('dst')
-       136±0.1ms       120±0.06ms     0.89  timeseries.DatetimeIndex.time_to_pydatetime('tz_aware')
-     29.8±0.07ms       26.0±0.1ms     0.87  timeseries.Iteration.time_iter_preexit(<function period_range at 0x7f36ac823de8>)
-         935±1μs          731±2μs     0.78  timeseries.DatetimeIndex.time_to_pydatetime('dst')

taskset 6 asv continuous -f 1.1 -E virtualenv master HEAD -b timeseries
[...]
       before           after         ratio
     [3cb64bd2]       [76e0c080]
-       294±0.2ms          263±1ms     0.89  timeseries.ToDatetimeISO8601.time_iso8601_tz_spaceformat
-     7.38±0.03μs      6.50±0.04μs     0.88  timeseries.DatetimeIndex.time_get('tz_aware')
-      10.6±0.1ms         7.75±0ms     0.73  timeseries.ToDatetimeISO8601.time_iso8601

[jreback]

thanks @jbrockmendel happy to have cleanups

[jreback]

on build getting

warning: pandas/_libs/tslibs/conversion.pyx:614:39: Buffer unpacking not optimized away.
warning: pandas/_libs/tslibs/conversion.pyx:614:39: Buffer unpacking not optimized away.

if you have chance

[jbrockmendel]

warning: pandas/_libs/tslibs/conversion.pyx:614:39: Buffer unpacking not optimized away

I'm pretty sure this has to do with the return type being int64_t[:], will see if there's anything that can be done about it.