strftime/strptime round trip fails even for UTC datetime object

[4kir4]

BPO	22241
Nosy	@gvanrossum, @brettcannon, @mdickinson, @abalkin, @4kir4, @berkerpeksag
Files	issue22241.diff issue22241-2.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/abalkin'
closed_at = <Date 2015-09-06.17:09:43.595>
created_at = <Date 2014-08-21.11:35:17.541>
labels = ['extension-modules', 'easy', 'type-bug', 'library']
title = 'strftime/strptime round trip fails even for UTC datetime object'
updated_at = <Date 2015-09-07.22:15:43.454>
user = 'https://github.com/4kir4'

bugs.python.org fields:

activity = <Date 2015-09-07.22:15:43.454>
actor = 'python-dev'
assignee = 'belopolsky'
closed = True
closed_date = <Date 2015-09-06.17:09:43.595>
closer = 'belopolsky'
components = ['Extension Modules', 'Library (Lib)']
creation = <Date 2014-08-21.11:35:17.541>
creator = 'akira'
dependencies = []
files = ['40284', '40382']
hgrepos = []
issue_num = 22241
keywords = ['patch', 'easy']
message_count = 12.0
messages = ['225606', '225609', '225623', '225625', '225626', '225630', '225644', '249211', '249627', '249999', '250000', '250133']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'brett.cannon', 'mark.dickinson', 'belopolsky', 'akira', 'python-dev', 'berker.peksag']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22241'
versions = ['Python 3.6']

[4kir4]

>>> from datetime import datetime, timezone
  >>> dt = datetime.now(timezone.utc)
  >>> fmt = '%Y-%m-%d %H:%M:%S.%f %Z%z'
  >>> datetime.strptime(dt.strftime(fmt), fmt)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/cpython/Lib/_strptime.py", line 500, in _strptime_datetime
      tt, fraction = _strptime(data_string, format)
    File "/cpython/Lib/_strptime.py", line 337, in _strptime
      (data_string, format))
  ValueError: time data '2014-08-21 11:29:13.537251 UTC+00:00+0000'
  does not match format '%Y-%m-%d %H:%M:%S.%f %Z%z'

The issue is that dt.strftime('%Z') produces 'UTC+00:00'
(due to timezone.utc.tzname(dt) returning 'UTC+00:00')
instead of 'UTC' that strptime() accepts and %Z examples [1]
in the docs demonstrate.

[1] https://docs.python.org/3.4/library/datetime.html#strftime-and-strptime-behavior

[abalkin]

This is a duplicate of bpo-15873.

[4kir4]

I don't see, how it is a duplicate. Everything works if pytz.utc (.tzname() == 'UTC')
is used instead of timezone.utc (.tzname() == 'UTC+00:00').
Everything works if UTC class from the example [1]
in the tzinfo docs is used.
It only breaks due to the weird timezone.utc.tzname() return value.

[1] https://docs.python.org/3.4/library/datetime.html#datetime.tzinfo.fromutc

Why does datetime.now(timezone.utc).strftime('%Z')
(via timezone.utc.tzname(dt)) produce 'UTC+00:00'?
How is it motivated?
Is it documented somewhere?
Can datetime.now(timezone.utc).strftime('%Z') be changed to return 'UTC'?

[abalkin]

I see. I thought you were complaining about "%z" format not supporting "00:00" as in

>>> from datetime import *
>>> datetime.strptime("00:00","%z")
Traceback (most recent call last):
 ..
ValueError: time data '00:00' does not match format '%z'

but your issue is that %Z does not parse "UTC+00:00" as in

>>> datetime.strptime("UTC+00:00x","%Zx")
Traceback (most recent call last):
 ..
ValueError: time data 'UTC+00:00x' does not match format '%Zx'

The name produced by timezone when no name is explicitly specified is documented:

https://docs.python.org/3.4/library/datetime.html#datetime.timezone.tzname

Can datetime.now(timezone.utc).strftime('%Z') be changed to return 'UTC'?

I think it can. I am surprised this did not come up in bpo-5094 where UTC±hh:mm syntax was discussed.

The change would be trivial - just supply explicit name to utc singleton.

Please ask on Python-Dev if anyone would object.

[abalkin]

See also <http://bugs.python.org/issue5094#msg106476\>.

It looks like providing 'UTC' as the name of utc singleton was part of my original proposal. I have no recollection on why it was not implemented that way.

[abalkin]

Akira,

I see that you participated in the original discussion (msg107608). We settled on str(timezone.utc) == 'UTC+00:00' and this was clearly a deliberate choice. I don't think we can revisit this now, but we can probably make strptime smart enough to parse UTC±hh:mm with %Z format code.

[4kir4]

I see that you participated in the original discussion (msg107608).
We settled on str(timezone.utc) == 'UTC+00:00' and this was clearly a
deliberate choice. I don't think we can revisit this now, but we can
probably make strptime smart enough to parse UTC±hh:mm with %Z format
code.

I see it advocates either 'UTC' or '+00:00' ('-00:00' is semantically
different) i.e., mutually exclusive options: UTC is special enough
(it is a real timezone that is widely used) to warrant 'UTC' name. On
the other hand '+HH:MM' (%:z) (note: *without* 'UTC' prefix) is easily
extendable for a fixed-offset tzinfo family and it allows to use %Z to
generate/parse date/time strings with rfc3339-like utc offset and the
"numeric" tzname() would stress that a fixed-offset datetime.timezone
doesn't represent "real" zoneinfo timezone.

UTC+HH:MM is neither here nor there: it is easily confusable with
deprecated :GMT+H, Etc/GMT-H zoneinfo timezones (I'm not sure about
the signs) and it doesn't help generate/parse isoformat() strings
e.g., it confuses dateutil.parser therefore *strftime('... %Z') with
datetime.timezone should be avoided.*

pytz is *the* module that exposes zoneinfo (the timezone database)
to Python. Its tzname() methods (and therefore strftime('%Z')) produce
timezone abbreviations such as 'UTC', 'EST', 'CST' (all %Z examples in
datetime docs) that may be ambiguous (the same abbreviation can be
used by several timezones) and in reverse -- a single timezone can use
several abbreviations for the same purpose (non-DST related). I find
'%Z%z' to be easier to read at a glance compared to %z along (imagine
you look at dozens timestamps at once e.g., in a log collected from
several machines).