ERR: stricter checks on Index construction when tz is passed

[jreback]

from comment on #13981

In [1]: pd.Index([datetime.datetime(2012,1,1), datetime.datetime(2012,1, 2)], tz="Europe/Brussels")
Out[1]: DatetimeIndex(['2012-01-01 00:00:00+01:00', '2012-01-02 00:00:00+01:00'], dtype='datetime64[ns, Europe/Brussels]', freq=None)

In [2]: pd.Index([1, 2], tz="Europe/Brussels")
Out[2]: DatetimeIndex(['1970-01-01 00:00:00+01:00', '1970-01-01 00:00:00+01:00'], dtype='datetime64[ns, Europe/Brussels]', freq=None)

In [3]: pd.Index(['20120102', '20120103'], tz="Europe/Brussels")
Out[3]: DatetimeIndex(['2012-01-02 00:00:00+01:00', '2012-01-03 00:00:00+01:00'], dtype='datetime64[ns, Europe/Brussels]', freq=None)

[1] is fine/expected
[2] should be disallowed (e.g. integer construction)
[3] is ok, maybe should disallow to be consistent.

I am not sure what this would break. But we don't necessarily want to force datetime construction on a generic Index (as opposed to using .to_datetime or a constructor, e.g. pd.date_range). This is a bit too much inference.

So the rule would be that it has to be actual datetimes/Timestamps, if tz is provided (which is a form of dtype).

[jreback]

@jorisvandenbossche @sinhrks

[jorisvandenbossche]

+1 on disallowing [1] and [2].
I personally also do not really like that you can pass tz in Index (as this is not documented), but it's ok that that returns a DatetimeIndex

[sinhrks]

I think passing tz to normal Index may better to be deprecated as it is ambiguous (so disallow [1], [2] and [3]).

I assume the behavior was a workaround to keep DatetimeIndex as a MultiIndex level (solved after #13981).