Polars seems to enforce some kind of handling for ambiguous datetimes through this API, we can either error, raise, or replace them but all seem to rely on identifying if they exist and where. This is problematic for us short term in the very general case because we'd likely have to write some careful logic and tests to do this properly.

Are there any conditions we can think of that preclude the possibility of this occurring, like maybe requiring that the format specify UTC for now?

Polars seems to enforce some kind of handling for ambiguous datetimes through this API, we can either error, raise, or replace them but all seem to rely on identifying if they exist and where. This is problematic for us short term in the very general case because we'd likely have to write some careful logic and tests to do this properly.

Are there any conditions we can think of that preclude the possibility of this occurring, like maybe requiring that the format specify UTC for now?

Paging @mroeschke who has done a load of this in cudf-classic for the pandas compatibility.

If we think the answer is "it's too complicated", let's just not support unconditionally and write up properly as an issue.

Both %z and %Z raise in cudf classic currently as NotImplementedError

As you alluded to, a %Z in the format matching UTC exactly is the only safe timezone localization without introspecting the data. Technically any string matching %z could be supported since it should be treated as an "arbitrary UTC offset", but there's no way to represent that in the dtype today.

Both %z and %Z raise in cudf classic currently as NotImplementedError

As you alluded to, a %Z in the format matching UTC exactly is the only safe timezone localization without introspecting the data. Technically any string matching %z could be supported since it should be treated as an "arbitrary UTC offset", but there's no way to represent that in the dtype today.

Thanks @mroeschke , please correct me if I am wrong, but I think this means we should at least be able to proceed with the case of %Z - my reasoning here being that if we assume the data is all normalized to UTC, no instant in time should be ambiguous, so any kind of "handling" should be a no-op.

Thanks @mroeschke , please correct me if I am wrong, but I think this means we should at least be able to proceed with the case of %Z - my reasoning here being that if we assume the data is all normalized to UTC, no instant in time should be ambiguous, so any kind of "handling" should be a no-op.

assume the data is all normalized to UTC

Internally within cudf we can assume this. From polars I'm not sure if this can be assumed, especially if it's directly from user input. e.g.:

df = pl.DataFrame({"a": ["2024-03-10 02:30:00 US/Pacific"]})
df.select(pl.col("a").str.to_datetime(format="%Y-%m-%d %H:%M:%S %Z"))

should raise as 2024-03-10 02:30:00 is not a valid date and time in US/Pacific