BUG: in a level of MultiIndex tz info is lost from labels that represent the same timestamp

[maread99]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd

ts = pd.Timestamp("2023-07-19 14:23", tz="America/New_York")
ts_hk = ts.astimezone("Asia/Hong_Kong")
idx = pd.Index([ts, ts_hk])
idx
# Index([2023-07-19 14:23:00-04:00, 2023-07-20 02:23:00+08:00], dtype='object')

idx[-1].tz
# <DstTzInfo 'Asia/Hong_Kong' HKT+8:00:00 STD>

mi = pd.MultiIndex.from_arrays((("a","b"), idx))
mi
# MultiIndex([('a', '2023-07-19 14:23:00-04:00'),
#             ('b', '2023-07-19 14:23:00-04:00')],
#           )

mi[-1][-1].tz
# <DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>

Issue Description

Hi there!

When creating a pd.Index with dtype "object" it's possible to have multiple labels representing the same timestamp in different timezones, as reproducible example:

>>> ts = pd.Timestamp("2023-07-19 14:23", tz="America/New_York")
>>> ts_hk = ts.astimezone("Asia/Hong_Kong")
>>> idx = pd.Index([ts, ts_hk])
>>> idx

Index([2023-07-19 14:23:00-04:00, 2023-07-20 02:23:00+08:00], dtype='object')

>>> idx[-1].tz

<DstTzInfo 'Asia/Hong_Kong' HKT+8:00:00 STD>

However, I can't find a way of retaining this behaviour in a level of a pd.MultiIndex, rather all labels that represent the same timestamp are forced to the timezone of the first such instance, as reproducible example:

>>> mi = pd.MultiIndex.from_arrays((("a","b"), idx))
>>> mi

MultiIndex([('a', '2023-07-19 14:23:00-04:00'),
            ('b', '2023-07-19 14:23:00-04:00')],
           )

>>> mi[-1][-1].tz

<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>

Expected Behavior

Given that different timezones (for the same timestamp) can be represented by a pd.Index, I would have expected the same behaviour from a level of a pd.MultiIndex. Is this a bug or is it simply (EDIT that all values of a level must be unique and pd.Timestamp are considered unique based on the underlying timestamp, independent of any timezone?) how MultiIndex work given that the values are recorded in FrozenSet and all Timestamp representing the same underlying timestamp compare as equal, regardless of timezone, such that only one concrete representation can be included in the set? Or am I barking up the completely wrong tree?

Thank you!

Installed Versions

INSTALLED VERSIONS

commit : 0f43794
python : 3.8.10.final.0
python-bits : 64
OS : Windows
OS-release : 10
Version : 10.0.22621
machine : AMD64
processor : Intel64 Family 6 Model 141 Stepping 1, GenuineIntel
byteorder : little
LC_ALL : None
LANG : None
LOCALE : English_United Kingdom.1252

pandas : 2.0.3
numpy : 1.24.4
pytz : 2023.3
dateutil : 2.8.2
setuptools : 68.0.0
pip : 23.2
Cython : None
pytest : 7.4.0
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.9.1
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : 8.6.0
pandas_datareader: None
bs4 : None
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : 0.9.0
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None

[MarcoGorelli]

Hi @maread99 - just out of interest, what's your use case for mixed timezones within the same Index?

[maread99]

Hi @MarcoGorelli. The yahooquery package provides for returning, in a single DataFrame, intraday OHLC data covering multiple securities trading on different exchanges in different timezones. There's an option to set the 'date' level of the MultiIndex as UTC or in the timezone of the security identified by the 'symbol' level.

This yahooquery issue shows this in the context of the problem we've run into that led me to raise this issue here.