This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, mark.dickinson, pitrou, rafe, vstinner
Date 2010-06-04.14:17:20
SpamBayes Score 6.9251e-07
Marked as misclassified No
Message-id <>
In-reply-to <>
On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson <> wrote:
> Aren't there valid timezones that are offset by more than 12 hours from UTC?

Indeed, Christmas Island uses UTC+14. (

The most western timezone seems to be UTC-12 used on two uninhabited
islands. <>

The tzinfo specification requires [-24, 24] hours range:

.. the value returned must be a timedelta object specifying a whole
number of minutes in the range -1439 to 1439 inclusive (1440 = 24*60;
the magnitude of the offset must be less than one day).
""" --

I am torn between two options with a slight preference for the first:

1. Don't do any checking in the constructor and allow any timedelta
used as an offset.  This is the simplest to implement and most future
proof.  For example, it may be desirable to extend [-24, 24] to at
least [-99, 99] to allow round-tripping of compliant RFC 3339
timestamps.  (Note that I am not suggesting that real life more than a
day offsets are possible, but once a standard allows impossible
values, people tend to abuse them as special markers in their data.)

2. Require [-24, 24] hours range.  This is the letter of the current
tzinfo.utcoffset() definition.


What do you think
Date User Action Args
2010-06-04 14:17:23belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, mark.dickinson, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-06-04 14:17:21belopolskylinkissue5094 messages
2010-06-04 14:17:21belopolskycreate