BUG: Timestamp.to_pydatetime losing 'fold' by jbrockmendel · Pull Request #45087 · pandas-dev/pandas (original) (raw)

Not sure what to make of this test failure. Is it obvious whether the problem is with the current behavior vs with the patch?

I don't really understand why that test is expecting dateutil and pytz to have different behaviors for this particular datetime. The documentation for tz_localize seems to indicate that ambiguous is used to specify which side of the DST transition you want:

bool contains flags to determine if time is dst or not (note that this flag is only applicable for ambiguous fall dst dates).

It seems unclear whether this means that 0 == DST and 1 == STD, but if that's the case you will run into the semantic differences between is_dst and fold if you try to map ambiguous to a specific version of the flag.

In any case, the test at least seems wrong, because of this part:

    assert result_pytz.value == result_dateutil.value
    assert result_pytz.value == 1382835600000000000

    # fixed ambiguous behavior
    # see gh-14621
    assert result_pytz.to_pydatetime().tzname() == "GMT"
    assert result_dateutil.to_pydatetime().tzname() == "BST"

If I understand correctly, .value is a fixed offset from the unix epoch in nanoseconds. If it's the same for the pytz result and the dateutil result, then tzname() should also be the same. The correct answer for that timestamp is GMT:

import zoneinfo from datetime import datetime LON = zoneinfo.ZoneInfo("Europe/London") datetime.datetime(2013, 10, 27, 1, 0, fold=1, tzinfo=zoneinfo.ZoneInfo(key='Europe/London')) datetime.fromtimestamp(1382835600, tz=LON).tzname() 'GMT'

I recommend adding a corresponding test in a zone with negative DST to make sure you aren't doing the wrong thing somewhere in the chain of logic.