[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky report at bugs.python.org
Fri Jun 4 16:17:23 CEST 2010


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> Aren't there valid timezones that are offset by more than 12 hours from UTC?

Indeed, Christmas Island uses UTC+14. (http://en.wikipedia.org/wiki/Kiritimati).

The most western timezone seems to be UTC-12 used on two uninhabited
islands. <http://en.wikipedia.org/wiki/Time_zone#Time_zone_as_offsets_from_UTC>

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).
""" -- http://docs.python.org/dev/py3k/library/datetime.html#datetime.tzinfo.utcoffset

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.

Opinions?

What do you think

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________


More information about the Python-bugs-list mailing list