[Datetime-SIG] Drop datetime's offset restrictions?

M.-A. Lemburg mal at egenix.com
Wed Aug 12 23:19:41 CEST 2015

On 12.08.2015 22:44, Chris Barker wrote:
> On Wed, Aug 12, 2015 at 9:05 AM, Alexander Belopolsky <
> alexander.belopolsky at gmail.com> wrote:
>> On Wed, Aug 12, 2015 at 11:37 AM, Chris Barker - NOAA Federal
>> <chris.barker at noaa.gov> wrote:
>>>> Whaddya think?  Continue nagging people for no reason at all, or let
>>>> freedom bloom? ;-)
>>> As long as we're poking around in datetime, I say let freedom bloom!
>> +0, but will be +1 if someone comes up with a specific proposal on how
>> printing and parsing of
>> extended precision timezones will work.
>> See e.g., <http://bugs.python.org/issue15873>.
> I'm a bit confused on what one has to do with the other?
> Or is this about the fact that ISO 8601 seems to specify that the offset be
> defined as:
> so no room for seconds? Though it's seems the obvious extension is to
> simply add the seconds:
> Not that parsing of ISO 8601 is not a great idea to have in datetime. I've
> often wondered why it isn't there.

I'd say: simply drop the seconds offset on output. It's better to
conform to the standard than to break interoperability:


For those few cases where you'd need them, you can fiddle
with the time specification before the UTC offset to have
the end result still represent the correct point in

> BTW,  numpy's datetime64 does have it, and it's more or less the standard
> way to create one. No idea what it does if you try to pass in an offset
> with seconds... -- yes, I do, not hard to check:
> In [54]: np.datetime64('2015-08-03T13:12:11-07:00:13')
> ---------------------------------------------------------------------------
> ValueError                                Traceback (most recent call last)
> <ipython-input-54-da564c1b4acf> in <module>()
> ----> 1 np.datetime64('2015-08-03T13:12:11-07:00:13')
> ValueError: Error parsing datetime string "2015-08-03T13:12:11-07:00:13" at
> position 25
> The problem I see with ISO 8601 is that (AFAICT) there is no way to specify
> a time zone -- only a UTC offset.
> and offsets are not unique.

Using UTC offsets is the only sane way to write down a point in time
without having to carry around Her Majesty's Nautical Almanac
all the time :-)

Seriously, timezone names are ambiguous and a rather poor way to
spell a time, unless you have additional context to help you decipher
the time zone, look up the regular UTC offset (they tend to change every
so often), check for DST and then take it from there.

The Olson database is an interesting read on this subject, e.g.

> So if someone wants to create a datetime object from an ISO 8601 string,
> they have two options:
>  * The string does not contain an offset -- they should get a naive datetime
>  * The string does contain an offset -- they have to get a datetime with a
> UTC tzinfo object, with the offset having been applied.
> Is there any issue here other than someone needs to find or write the code
> and persuade everyone that it's clean an maintainable enough for the stdlib?

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Aug 12 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
2015-08-12: Released mxODBC 3.3.4 ...             http://egenix.com/go80
2015-07-30: Released eGenix pyOpenSSL 0.13.11 ... http://egenix.com/go81
2015-08-22: FrOSCon 2015 ...                               10 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Datetime-SIG mailing list