BUG: Calling tz_localize suppresses ValueError when converting from NaT to np.int64

[vdonato]

• 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.

---

Code Sample, a copy-pastable example

import numpy as np
import pandas as pd

ser = pd.Series([pd.NaT], dtype="datetime64[ns]")
ser = ser.dt.tz_localize("America/Los_Angeles")

print(ser.astype(np.int64)[0])

Problem description

The code snippet above prints -9223372036854775808 (-2⁶³) instead of raising a ValueError, which is the behavior that would occur if tz_localize were not called.

Expected Output

Should raise a ValueError: Cannot convert NaT values to integer.

Output of pd.show_versions()

INSTALLED VERSIONS

commit : 3e89b4c
python : 3.8.5.final.0
python-bits : 64
OS : Linux
OS-release : 5.8.0-36-generic
Version : #40~20.04.1-Ubuntu SMP Wed Jan 6 10:15:55 UTC 2021
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.2.0
numpy : 1.19.5
pytz : 2020.5
dateutil : 2.8.1
pip : 20.3.3
setuptools : 51.0.0
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader: None
bs4 : None
bottleneck : None
fsspec : None
fastparquet : None
gcsfs : None
matplotlib : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
numba : None

[jreback]

hmm the error is not that a datetime64[ns, UTC} is raise, rather its the reverse, we are raising on a all-NaT datetime64[ns] when converting to np.int64 which is unlike numpy

In [51]: ser.dt.tz_localize(None).values.astype('int64')
Out[51]: array([-9223372036854775808])

while we raise

note that there is a warning on this in current master for using .astype though .view has the same behavior

[jreback]

cc @jbrockmendel

[jbrockmendel]

ATM both of these cases issue a FutureWarning that the astype is deprecated and will raise. i.e. i think this is as correct as its going to get until 2.0

[mroeschke]

Agreed. Since this behavior was deprecated, closing