When trying to use hypothesis to test whether there's a 1->1 mapping of pytz zones to dateutil zones, I wrote the following test:

from hypothesis import given, assume
from hypothesis import strategies as st
from hypothesis.extra import pytz as hepytz

from dateutil import tz
from datetime import datetime

@given(dt=st.datetimes(), tzi=hepytz.timezones())
def test_dateutil_compat(dt, tzi):
    # Test passes if you remove this assertion
    # assume(dt < datetime(2038, 1, 1))
    tzi_du = tz.gettz(str(tzi))
    dt_pytz = tzi.localize(dt)
    dt_du = dt.replace(tzinfo=tzi_du)

    assert dt_pytz == dt_du

This property is falsified by various examples after 2038-01-01:

E       AssertionError: assert datetime.datetime(2038, 1, 1, 0, 0, tzinfo=<DstTzInfo 'America/Campo_Grande' -03-1 day, 21:00:00 DST>) == datetime.datetime(2038, 1, 1, 0, 0, tzinfo=tzfile('/usr/share/zoneinfo/America/Campo_Grande'))

E       AssertionError: assert datetime.datetime(2038, 1, 1, 0, 0, tzinfo=<DstTzInfo 'Antarctica/South_Pole' NZDT+13:00:00 DST>) == datetime.datetime(2038, 1, 1, 0, 0, tzinfo=tzfile('/usr/share/zoneinfo/Antarctica/South_Pole'))

This is probably partially related to #462, since 2038 is the last year that there transitions in the 32-bit version of the files, but I am guessing that this means that we're doing the "default" rule differently from how pytz does it. I'm not sure who is right, but I wouldn't be surprised if it were pytz. I think we should fix this before #462, because since pytz does not support the 64-bit format, once we add support it may break the symmetry without solving the real problem.