DEPR: Deprecate generic timestamp dtypes 
We only use the nanosecond frequency, and `numpy` doesn't even handle generic timestamp `dtype` well internally with its `ndarray` object.

xref <a href="https://github.com/pandas-dev/pandas/issues/15524#issuecomment-282922120">#15524 (comment)</a>.
# [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=h1) Report
> Merging [#15987](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/7b8a6b1bc22f6fc0023c02ac8301e07b4ab80417?src=pr&el=desc) will **decrease** coverage by `0.01%`.
> The diff coverage is `100%`.

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

```diff
@@            Coverage Diff             @@
##           master   #15987      +/-   ##
==========================================
- Coverage   91.03%   91.01%   -0.02%     
==========================================
  Files         145      145              
  Lines       49587    49585       -2     
==========================================
- Hits        45141    45132       -9     
- Misses       4446     4453       +7
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `88.78% <100%> (-0.02%)` | :arrow_down: |
| #single | `40.57% <33.33%> (ø)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/core/internals.py](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW50ZXJuYWxzLnB5) | `93.55% <100%> (ø)` | :arrow_up: |
| [pandas/types/cast.py](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree#diff-cGFuZGFzL3R5cGVzL2Nhc3QucHk=) | `86.51% <100%> (+0.77%)` | :arrow_up: |
| [pandas/tools/plotting.py](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree#diff-cGFuZGFzL3Rvb2xzL3Bsb3R0aW5nLnB5) | `71.75% <0%> (-0.72%)` | :arrow_down: |
| [pandas/core/common.py](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvY29tbW9uLnB5) | `91.03% <0%> (+0.34%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/15987?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/15987?src=pr&el=footer). Last update [7b8a6b1...d581e3e](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=h1) Report
> Merging [#15987](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/cd35d22a04e22aa6a0ca6a98633fbe654f087960?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/15987/graphs/tree.svg?token=eZ4WkYLtcO&src=pr&height=150&width=650)](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master   #15987      +/-   ##
==========================================
+ Coverage      91%   91.01%   +<.01%     
==========================================
  Files         145      145              
  Lines       49639    49649      +10     
==========================================
+ Hits        45175    45188      +13     
+ Misses       4464     4461       -3
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `88.78% <100%> (ø)` | :arrow_up: |
| #single | `40.53% <25%> (-0.01%)` | :arrow_down: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/types/cast.py](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree#diff-cGFuZGFzL3R5cGVzL2Nhc3QucHk=) | `86.14% <100%> (+1.02%)` | :arrow_up: |
| [pandas/core/common.py](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvY29tbW9uLnB5) | `90.68% <0%> (-0.35%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/15987?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/15987?src=pr&el=footer). Last update [cd35d22...eb4df87](https://codecov.io/gh/pandas-dev/pandas/pull/15987?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). @jreback : All comments have been addressed, and everything is green. In the issue, the discussion was about construction of empty series objects, while here you also added constructing/astyping actual data with non-parameterized np.datetime64. As I said in the issue (https://github.com/pandas-dev/pandas/issues/15524#issuecomment-293497082, so my comment was relevant after all :-)), I don't see a strong reason to allow this. @gfyoung I see now you replied in the issue:

> Those examples you bring up above, should we follow in numpy 's footsteps? We only use one frequency, so I don't see why those two examples wouldn't work.

There is maybe not a strong reason that they shouldn't work, but I also don't see a good reason that they *should* work. It just expands what users can do in an unnecessary way. Why is it needed that people can do `.astype(np.datetime)` while they already can do `.astype('datetime64[ns]')` which is just more explicit (and does not 'misuse' the numpy dtype by interpreting it differently as numpy intended). @jorisvandenbossche : Well, it has to go one way or the other.  Either you can `astype` and initialize with the `dtype` (empty or non-empty), or you can't do either.  The consensus with @jreback was that you should be able to do both.  The point of this PR was to make behavior consistent.

I don't have any major issues going the other way and preventing anyone from casting to the generic `dtype` (i.e. `np.datetime64` or `np.timedelta64`) via `astype` or the constructor (though personally, having this convenience is nice because I sometimes forget how to format / exactly specify the frequency).  However, some agreement on how to proceed with this would be good. I am ok with this (still have to review the change again) as we already support this.

```
In [4]: Series([]).astype(np.datetime64)
Out[4]: Series([], dtype: datetime64[ns])
```
this should be consistent with direct construction (via ``dtype``). On second though, we could deprecate accepting direct ``np.datetime64`` as a passed dtype (this doesn't affect accept an array already in this format, just the ``dtype=`` kw and ``.astype()``)

So the principal of construction / conversion should work with the same type will be preserved.

I think I do like being more explicit here (IOW doing the deprecation). @gfyoung can you see what this breaks? 

IIRC this was originally an issue to fix something in csv parsing. But this was an orthogonal change (I don't even really understand *how* this change was related, maybe you can show that?) > (this doesn't affect accept an array already in this format, just the dtype= kw and .astype())

And for `dtype=` it already fails:
```
In [5]: Series([], dtype=np.datetime64)
...
TypeError: cannot convert datetimelike to dtype [datetime64]
```

so it is only `astype` that would change.

If possible, I would be in favor of not allowing bare `np.datetime64` (and thus deprecating the astype case) @jorisvandenbossche yep its the ``.astype`` that works *now*, not the direct construction. So let's investigate deprecating directly specifying ``np.datetime64``, ``np.timedelta64`` in ``.astype`` and see what happens. @jreback , @jorisvandenbossche : That sounds like a good plan.  Shouldn't be too bad I imagine.

@jorisvandenbossche BTW, the reason for that weird error message that you saw in the issue <a href="https://github.com/pandas-dev/pandas/issues/15524#issuecomment-293530014">here</a> is because at some point, we call `arr.view(dtype)`, which when `dtype=np.datetime64` causes `numpy` to get angry (internal representation breaks), and it can't display a proper error message. Deprecation worked out reasonably well, but I can't really figure out why AppVeyor and Circle are failing my tests.  The Travis logs are clean (and passing), so I don't think that there's any hidden warning being issued that's causing AppVeyor and Circle to miss them.

Suggestions on how to fix this? lgtm. I see you 'fixed' the passing ``np.datetime64`` to the constructor (and then deprecated it), but that's fine.

ping on green. Sounds good...once I can figure out these warnings 😁 @jreback : Everything is green again! thanks!