BUG: to_parquet() / read_parquet() cannot round-trip datetime.timezone.utc

[magic-david]

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

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

• (optional) I have confirmed this bug exists on the master branch of pandas.

---

Note: Please read this guide detailing how to provide the necessary information for us to reproduce your bug.

Code Sample, a copy-pastable example

import datetime
import pandas as pd

utc = datetime.timezone.utc
now = lambda: datetime.datetime.now(utc)

df = pd.DataFrame([[now(), "a"], [now(), "b"]], columns=("date", "val"))
df.set_index('date', inplace=True)

df.to_parquet('/tmp/a.parquet')
d2 = pd.read_parquet('/tmp/a.parquet')

# Kaboom

Problem description

Current behaviour:

• Silently writes a Parquet file that cannot be re-read
• Failure appears to be a missing check during write, however error confusing appears during read

Expected Output

Output of pd.show_versions()

INSTALLED VERSIONS

commit : b5958ee
python : 3.8.0.final.0
python-bits : 64
OS : Linux
OS-release : 5.3.0-24-generic
Version : #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : en_GB.UTF-8
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8

pandas : 1.1.5
numpy : 1.19.0
pytz : 2020.4
dateutil : 2.8.0
pip : 20.3.1
setuptools : 40.8.0
Cython : 0.29.20
pytest : 6.2.0
hypothesis : None
sphinx : 3.2.1
blosc : None
feather : None
xlsxwriter : None
lxml.etree : 4.5.1
html5lib : 1.1
pymysql : None
psycopg2 : 2.8.6 (dt dec pq3 ext lo64)
jinja2 : 2.11.2
IPython : 7.16.1
pandas_datareader: None
bs4 : 4.9.3
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : 3.3.2
numexpr : 2.7.1
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 1.0.1
pytables : None
pyxlsb : None
s3fs : None
scipy : 1.5.0
sqlalchemy : 1.3.20
tables : None
tabulate : 0.8.7
xarray : None
xlrd : None
xlwt : None
numba : 0.52.0

[magic-david]

Oh man, spent forever researching this and a simple 'pip install -U pyarrow' instantly cures it. Sorry for spam

[jreback]

yeah this was fixed on pyarrow 2.x i think