Inconsistency in tz_convert_single? #17734
Description
Two things in tslib look slightly fishy, merit double-checking.
https://github.com/pandas-dev/pandas/blob/master/pandas/_libs/tslib.pyx#L3617
cpdef int64_t tz_convert_single(int64_t val, object tz1, object tz2): [...] if get_timezone(tz2) == 'UTC': return utc_date if is_tzlocal(tz2): pandas_datetime_to_datetimestruct(val, PANDAS_FR_ns, &dts) # <--- Is this right? dt = datetime(dts.year, dts.month, dts.day, dts.hour, dts.min, dts.sec, dts.us, tz2) delta = int(get_utcoffset(tz2, dt).total_seconds()) * 1000000000 return utc_date + delta [...] return utc_date + offset The piece that looks off is the use of val instead of utc_date. The analogous portion of tz_convert reads:
if is_tzlocal(tz2): for i in range(n): v = utc_dates[i] if v == NPY_NAT: result[i] = NPY_NAT else: pandas_datetime_to_datetimestruct(v, PANDAS_FR_ns, &dts) # < --- Is this right? dt = datetime(dts.year, dts.month, dts.day, dts.hour, dts.min, dts.sec, dts.us, tz2) delta = (int(get_utcoffset(tz2, dt).total_seconds()) * 1000000000) result[i] = v + delta i.e. these appear inconsistent. Adding an assertion assert utc_date == val to the relevant case in tz_convert_single does not cause any test failures. Can someone confirm that this is correct as-is?
_localize_tso has a catch-all branch that looks like it should never be hit. If that is correct, then this can be simplified a decent amount.