Fix dask_cudf.read_parquet regression for legacy timestamp data

[rjzamora]

Description

cudf does not currently support timezone-aware datetime columns. For example:

    pdf = pd.DataFrame(
        {
            "time": pd.to_datetime(
                ["1996-01-02", "1996-12-01"],
                utc=True,
            ),
            "x": [1, 2],
        }
    )
    cudf.DataFrame.from_pandas(pdf)

NotImplementedError: cuDF does not yet support timezone-aware datetimes

However, cudf.read_parquet does allow you to read this same data from a Parquet file. This PR adds a simple fix to allow the same data to be read with dask_cudf. The dask_cudf version was previously "broken" because it relies on upstream pyarrow logic to construct meta as a pandas DataFrame (and then we just convert meta from pandas to cudf). As illustrated in the example above, this direct conversion is not allowed when one or more columns contain timezone information.

Important Context
The actual motivation for this PR is to fix a regression in 24.06+ for older parquet files containing "legacy" timestamp types (e.g. TIMESTAMP_MILLIS and TIMESTAMP_MICROS). In pyarrow 14.0.2 (used by cudf-24.04), these legacy types were not automatically translated to timezone-aware dtypes by pyarrow. In pyarrow 16.1.0 (used by cudf-24.06+), the legacy types ARE automatically translated. Therefore, in moving from cudf-24.04 to cudf-24.06+, some dask_cudf users will find that they can no longer read the same parquet file containing legacy timestamp data.

I'm not entirely sure if cudf should always allow users to read Parquet data with timezone-aware dtypes (e.g. if the timezone is not utc), but it definitely makes sense for cudf to ignore automatic/unnecessary timezone translations.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[rjzamora]

Note: Tried to add this to the proper "cuDF/Dask/..." project and get an error: "Sorry! We were unable to add the pull request to the selected project. Projects cannot have more than 1200 items."

[mroeschke]

So IIRC, if we do a deeper fix and allow .from_pandas to allow timezone aware pandas objects this would also fix the issue? IMO that fix should be relatively straightforward since there is some timezone support already in cudf

[rjzamora]

Thanks for the review @mroeschke !

So IIRC, if we do a deeper fix and allow .from_pandas to allow timezone aware pandas objects this would also fix the issue? IMO that fix should be relatively straightforward since there is some timezone support already in cudf

Yes. I would prefer a fix in cudf if you think that is reasonable :)

[mroeschke]

I opened up #15935 to hopefully supersede this PR

[wence-]

Note: Tried to add this to the proper "cuDF/Dask/..." project and get an error: "Sorry! We were unable to add the pull request to the selected project. Projects cannot have more than 1200 items."

We had not archived any completed items recently. I just cleared out a backlog of around 600 "DONE" items, which should have helped.

[wence-]

I think (to the best of my knowledge of timezones), this makes sense.

[rjzamora]

/merge