ENH: 2D compat for DTA tz_localize, to_period
State: closed

- [ ] closes #xxxx
- [x] tests added / passed
- [x] passes `black pandas`
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry


Labels:
name: Datetime
description: Datetime data dtype
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode

Comments:
btw who should i bug about resample/BinGrouper?
> btw who should i bug about resample/BinGrouper?

me or @mroeschke 
> Can you explain the rationale?

Two short-term motivations.  First, a number of places in DatetimeLikeBlock would be simpler if we just stored the EA as self.values, which requires more robust 2D support.  Second, I've got a branch implementing `__array_function__` and got some failures (dont remember which off the top of my head) that pushed this up the priority list.
> a number of places in DatetimeLikeBlock would be simpler if we just stored the EA as self.values, which requires more robust 2D support

Can you give a bit more details about which places that would be? 
I am personally -1 on storing the EA on 2D blocks. The 2D EA was a compromise for the block-wise ops, but expanding its usage first requires discussion IMO.

> Second, I've got a branch implementing `__array_function__` and got some failures

How is `to_period` or `tz_localize` related to `__array_function__`?

Also, IMO we should only add this for those functions for which we actually start using it. None of the changes here are actually already used somewhere?
>> a number of places in DatetimeLikeBlock would be simpler if we just stored the EA as self.values, which requires more robust 2D support

> Can you give a bit more details about which places that would be?

Most of these have `# TODO(EA2D):` comments: iget, diff, shift, set_inplace, get_values, quantile, fillna
> Most of these have # TODO(EA2D): comments: iget, diff, shift, set_inplace, get_values, quantile, fillna

I know you have been adding a lot of those comments, but having those comments doesn't mean there is consensus on further expanding the 2D capability of the datetimelike arrays ..

We could also make the DatetimeBlock a 1D non-consolidatable block, and that would also solve the datetime-specific TODO(EA2D) comments
> We could also make the DatetimeBlock a 1D non-consolidatable block

We're going to do essentially that in ArrayManager, which we're implementing so we can try it out and see what the performance/complexity impact is.  Fleshing out the 2D support for datetimelike arrays is part of making it possible to also try out the EA2D approach.
> > We could also make the DatetimeBlock a 1D non-consolidatable block
> 
> We're going to do essentially that in ArrayManager, which we're implementing so we can try it out and see what the performance/complexity impact is. Fleshing out the 2D support for datetimelike arrays is part of making it possible to also try out the EA2D approach.

I agree here. the array manager perf implications will determine our ultimate direction. e.g. if we get good performance then we should certainly move everything as it makes things code-wise way simpler. if not we have to re-think and potentially support 2d EA.
thanks @jbrockmendel