The datetime module only supports timezone offsets within 24 hours of UTC:

https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset

This seems like an arbitrary restriction, and prevents the library from being used in arbitrary timezone translations. For various reasons, one might need to start a new day (perhaps to implement some business logic) during the regular day. Depending on when/where this is, the effective offset can easily be greater than 24 hours.

>>> import datetime
>>> import pytz

>>> dt = pytz.utc.localize(datetime.datetime.utcnow())
>>> dt
datetime.datetime(2015, 8, 31, 23, 30, 55, 590037, tzinfo=<UTC>)

>>> tz = pytz.timezone('Pacific/Auckland_Custom')
>>> dt.astimezone(tz)
datetime.datetime(2015, 9, 2, 4, 30, 55, 590037, tzinfo=<DstTzInfo 'Pacific/Auckland_Custom' NZST+1 day, 5:00:00 STD>)

>>> dt_local = datetime.datetime.now()
>>> tz.localize(dt_local)
.../python2.7/site-packages/pytz/tzinfo.py in localize(self, dt, is_dst)
    314 loc_dt = tzinfo.normalize(dt.replace(tzinfo=tzinfo))
    315 if loc_dt.replace(tzinfo=None) == dt:
--> 316 possible_loc_dt.add(loc_dt)
    317
    318 if len(possible_loc_dt) == 1:

ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439


Note that although only offsets within 24 hours are supported, it seems to be possible to use astimezone() with arbitrary offsets. So perhaps we gain consistency in removing the restriction altogether?

This would not be unprecedented. RFC 2822 allows any offset
representable as HHMM: "the zone MUST be within the range -9959
through +9959" Section 3.3 of http://tools.ietf.org/html/rfc2822.html

The timezone offset range restriction is not arbitrary.  It was discussed in issue 5094 (see msg107059 and responses to it.)

Nevertheless, there is an open proposal to remove all restrictions on offset values and allow it to be an arbitrary timedelta.  See issue 5288, msg248468.

I think we should consolidate this issue with #5288.

BTW, the specific issue that OP complains about is not a datetime issue: apparently pytz has an even tighter restriction on timezone offsets.

I am going to close this as a third party issues, but those who support relaxing datetime.timezone restriction to ±24h range are invited to participate in issue 5288 discussion.

Thanks for the pointer to #5288. Happy to consolidate there.

In my reading of #5094 (from which I pulled your RFC 2822 reference), the justification I found was "For the allowable range, follow the datetime docs as someone might be relying on that specification already".  But this didn't explain why it was in the spec in the first place, and that is the decision I thought was arbitrary, not the decision to maintain the restriction. Splitting hairs at this point. Looking forward to the restriction being removed.

I always thought that restriction came from ISO 8601, but at the moment I don't have it to check.