Closed charlesbluca closed 1 year ago
Thanks @charlesbluca -- the following patch fixes this particular issue for me, but are you able to try it out with some other tests to see if things more or less work? If so, I'll go ahead and make a PR:
diff --git a/python/dask_cudf/dask_cudf/backends.py b/python/dask_cudf/dask_cudf/backends.py
index 378f46de22..e926911364 100644
--- a/python/dask_cudf/dask_cudf/backends.py
+++ b/python/dask_cudf/dask_cudf/backends.py
@@ -6,6 +6,7 @@ from collections.abc import Iterator
import cupy as cp
import numpy as np
import pandas as pd
+from pandas.core.tools.datetimes import is_datetime64tz_dtype
import pyarrow as pa
from pandas.api.types import is_scalar
@@ -122,6 +123,11 @@ def _get_non_empty_data(s):
data = cudf.core.column.as_column(data, dtype=s.dtype)
elif is_string_dtype(s.dtype):
data = pa.array(["cat", "dog"])
+ elif is_datetime64tz_dtype(s.dtype):
+ from cudf.utils.dtypes import get_time_unit
+
+ data = cudf.date_range("2001-01-01", periods=2, freq=get_time_unit(s))
+ data = data.tz_localize(str(s.dtype.tz))._column
else:
if pd.api.types.is_numeric_dtype(s.dtype):
data = cudf.core.column.as_column(
Describe the bug We currently get a
TypeError
during meta construction when attemptingsr.dt.tz_localize(...)
on a timezone-aware dask-cuDF series:Steps/Code to reproduce bug
Expected behavior Would expect this operation to pass and change the timezone of the datetime data accordingly.
Environment overview (please complete the following information)
Environment details
Click here to see environment details