Allow timezone offsets greater than 24 hours #69167

Activity

1. tjhnson commented on Sep 1, 2015

   

   tjhnsonmannequin

   on Sep 1, 2015

   MannequinAuthor

   More actions

   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
2. tjhnson

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   type-featureA feature request or enhancementA feature request or enhancement

   on Sep 1, 2015
3. abalkin commented on Sep 2, 2015

   

   abalkin

   on Sep 2, 2015

   Member

   More actions

   The timezone offset range restriction is not arbitrary. It was discussed in bpo-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 bpo-5288, msg248468.

   I think we should consolidate this issue with bpo-5288.
4. abalkin commented on Sep 2, 2015

   

   abalkin

   on Sep 2, 2015

   Member

   More actions

   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 bpo-5288 discussion.
5. abalkin

   closed this as completedon Sep 2, 2015
6. tjhnson commented on Sep 3, 2015

   

   tjhnsonmannequin

   on Sep 3, 2015

   MannequinAuthor

   More actions

   Thanks for the pointer to bpo-5288. Happy to consolidate there.

   In my reading of bpo-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.
7. abalkin commented on Sep 3, 2015

   

   abalkin

   on Sep 3, 2015

   Member

   More actions

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

   transferred this issue fromon Apr 10, 2022