Issue 24979: Allow timezone offsets greater than 24 hours (original) (raw)

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=)

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

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.