standardize post-call treatment of get_dst_info, delay sorting calls
State: closed

@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.

Labels:
name: Refactor
description: Internal refactoring of code
name: Datetime
description: Datetime data dtype
name: Internals
description: Related to non-user accessible pandas implementation

Comments:
# [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21960?src=pr&el=h1) Report
> Merging [#21960](https://codecov.io/gh/pandas-dev/pandas/pull/21960?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/3cb64bd2953fd264a3d0762806e800f58800641d?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/21960/graphs/tree.svg?token=eZ4WkYLtcO&width=650&src=pr&height=150)](https://codecov.io/gh/pandas-dev/pandas/pull/21960?src=pr&el=tree)

```diff
@@           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% <ø> (ø)` | :arrow_up: |
| #single | `42.23% <ø> (ø)` | :arrow_up: |


------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21960?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21960?src=pr&el=footer). Last update [3cb64bd...76e0c08](https://codecov.io/gh/pandas-dev/pandas/pull/21960?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).

looks fine. is there any perf diff?
>  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`
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
```

thanks @jbrockmendel happy to have cleanups
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
> 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.