Off-by-one-hour error converting Kaggle API competition deadlines from UTC to US/Eastern in pandas

Symptom

When converting competition deadline timestamps returned by the Kaggle API into US/Eastern for display and scheduling logic, the converted values come out one hour off from the expected wall-clock time. The raw values are ISO 8601 strings ending in Z, such as 2023-12-31T23:59:59.000Z.

Component and current approach

The pipeline parses the deadline field with pandas.to_datetime and then applies a pytz conversion to US/Eastern. The notebook kernel's system timezone is UTC, and tzinfo on the parsed column is None, so the datetimes are naive at the point of conversion. The discrepancy appears only for some dates, which suggests a daylight-saving boundary interaction rather than a constant offset bug.

Constraints

The Kaggle API offers no timezone parameter and returns UTC strings only, so all conversion must happen client-side. The same code runs both in Kaggle notebooks (UTC kernel) and locally, so the behavior must not depend on the machine's system timezone. Mixing naive and aware datetimes elsewhere in the pipeline has already caused silent comparison failures.

Questions

1. Is the one-hour drift caused by localizing naive datetimes directly to US/Eastern instead of localizing to UTC first and then converting?
2. Does pandas.to_datetime(..., utc=True) followed by tz_convert handle DST transitions correctly for all historical deadline dates?
3. Is there a supported way to make the conversion independent of the kernel's system timezone, short of normalizing every timestamp at ingestion?