BUG: DatetimeIndex._data should return an ndarray
State: closed

- [x] closes #20810
- [ ] tests added / passed
- [x] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [x] whatsnew entry

The change I made seems to fix the case in the original issue without breaking any tests. 

On my branch:
```
In [1]: idx1 = pd.DatetimeIndex(start="2012-01-01", periods=3, freq='D') # date_range kind of construction

In [2]: idx1._data
array(['2012-01-01T00:00:00.000000000', '2012-01-02T00:00:00.000000000',
       '2012-01-03T00:00:00.000000000'], dtype='datetime64[ns]')

In [3]: idx2 = pd.DatetimeIndex(idx1)

In [4]: idx2._data
Out[4]: 
array(['2012-01-01T00:00:00.000000000', '2012-01-02T00:00:00.000000000',
       '2012-01-03T00:00:00.000000000'], dtype='datetime64[ns]')
```

But is the solution too simple or is something more sophisticated required?

And do we need tests for this issue?

Labels:
name: Bug
name: Datetime
description: Datetime data dtype
name: Compat
description: pandas objects compatability with Numpy or Python functions

Comments:
this is a band aid
it shouldn’t be set in the first place like this
# [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/20912?src=pr&el=h1) Report
> Merging [#20912](https://codecov.io/gh/pandas-dev/pandas/pull/20912?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/d05e8f28c160206204ac26f62a831ef200ea9db0?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `100%`.

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

```diff
@@            Coverage Diff             @@
##           master   #20912      +/-   ##
==========================================
+ Coverage   91.92%   91.92%   +<.01%     
==========================================
  Files         160      160              
  Lines       49913    49915       +2     
==========================================
+ Hits        45882    45884       +2     
  Misses       4031     4031
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.3% <100%> (ø)` | :arrow_up: |
| #single | `42.11% <90.9%> (ø)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/20912?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/io/pytables.py](https://codecov.io/gh/pandas-dev/pandas/pull/20912/diff?src=pr&el=tree#diff-cGFuZGFzL2lvL3B5dGFibGVzLnB5) | `92.48% <100%> (ø)` | :arrow_up: |
| [pandas/core/indexes/base.py](https://codecov.io/gh/pandas-dev/pandas/pull/20912/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9iYXNlLnB5) | `96.58% <100%> (-0.06%)` | :arrow_down: |
| [pandas/core/indexes/datetimes.py](https://codecov.io/gh/pandas-dev/pandas/pull/20912/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9kYXRldGltZXMucHk=) | `95.21% <100%> (+0.11%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/20912?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/20912?src=pr&el=footer). Last update [d05e8f2...e18d996](https://codecov.io/gh/pandas-dev/pandas/pull/20912?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).

happy to take a patch with a non-band aid fix (or can close for now)
> this is a band aid
it shouldn’t be set in the first place like this

Can you be more specific than this? 
I don't think this fix is necessarily a band aid. 

Currently, the `index` object (which at the end of the `_generate` method is passed to `_simple_new`) is generated in some different ways:

- `cls._cached_range` -> returns DatetimeIndex
- `_generate_regular_range` -> returns DatetimeIndex
- passed through `conversion.tz_localize_to_utc` -> returns array
- `tools.to_datetime` -> returns DatetimeIndex

So possible fixes I see:

1) make sure that `index` is a DatetimeIndex in the end in all cases and update the final `_simple_new` call (this is what @reidy-p did)
2) make sure that each case results in a datetime64 array (this seems more work to do that conversion in each place)
3) just before the `_simple_new` call, check if `index` is a DatetimeIndex or not, and convert there to ndarray if needed
4) change `_simple_new` to convert DatetimeIndex to ndarray if passed one.

From those options, the first seems reasonable to me. I think 3) is also fine (although that is less explicit).

@jorisvandenbossche thanks for that summary!

@jreback do you agree with the above comment or is this still a band-aid?
Hello @reidy-p! Thanks for updating the PR.









Cheers ! There are no PEP8 issues in this Pull Request. :beers: 

##### Comment last updated on July 09, 2018 at 16:01 Hours UTC
@reidy-p if you can rebase. datetimes have been  changing a bit as getting ready for DatetimeArray cc @jbrockmendel 
Yeah sorry I just saw the new changes. I'll rebase.
@reidy-p lgtm. ping on green.
@jreback thanks! This is green now
thanks @reidy-p