datetime.isoformat() -> explicitly mark UTC string as such

[mirkovogt]

BPO	23332
Nosy	@abalkin, @bitdancer, @mirabilos

^{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 = None
closed_at = <Date 2015-08-28.21:36:37.214>
created_at = <Date 2015-01-27.17:37:29.892>
labels = ['type-bug', 'invalid']
title = 'datetime.isoformat() -> explicitly mark UTC string as such'
updated_at = <Date 2015-08-28.21:36:37.213>
user = 'https://bugs.python.org/mirkovogt'

bugs.python.org fields:

activity = <Date 2015-08-28.21:36:37.213>
actor = 'belopolsky'
assignee = 'none'
closed = True
closed_date = <Date 2015-08-28.21:36:37.214>
closer = 'belopolsky'
components = []
creation = <Date 2015-01-27.17:37:29.892>
creator = 'mirkovogt'
dependencies = []
files = []
hgrepos = []
issue_num = 23332
keywords = []
message_count = 23.0
messages = ['234829', '234831', '234832', '234834', '234835', '234836', '234837', '234838', '234839', '234841', '234842', '234843', '234844', '234845', '234889', '234891', '234892', '236748', '236750', '236751', '236752', '236762', '249299']
nosy_count = 5.0
nosy_names = ['belopolsky', 'r.david.murray', 'BreamoreBoy', 'mirabilos', 'mirkovogt']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23332'
versions = ['Python 3.6']

[mirkovogt]

I trapped into a pitfall today with web programming using DateTime.isoformat() in the backend and Javascript on the frontend side.

isoformat() string'yfies a DateTime-object according to ISO 8601, which states that, if no timezone is specified, the string is supposed to be interpreted as UTC implicitly. isoformat() doesn't append any TZ if the object is UTC - so far so good.

However when interacting with JavaScript that leads to errors, as the ECMAScript ed 6 draft states (and most browser act like that): "date time strings without a time zone are to be treated as local, not UTC)."[1]

That is not Python's fault - however considering the issues this behaviour could cause as well as following the philosophy 'explicit is better than implicit', I'd suggest explicitly marking UTC-strings as such by adding a trailing 'Z'. According ISO 8601 that is totally fine, optional though.

[1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

[bitdancer]

I wonder what the chances are that doing that would break other software with the opposite assumption (an assumption based on past Python behavior).

[mirkovogt]

Both implementations behave according the standard. If you assume otherwise you violate the standard - as JavaScript does.

If that change would break software, that software was broken from the beginning.

[mirkovogt]

Actually I'm not sure anymore whether NOT specifying a timezone is valid at all.

Even though the Spidermonkey documentation itself states, that it doesn't behave according to the ISO standard, several documents say that specifying the timezone is crucial (either "Z" or "+/-XX:XX").

I also found documents describing the standard which explicitly state that by default the local time is assumed, as JavaScript does.

Either way - there's so much different information and therewith confusion out there, that I highly recommend always specifying the timezone and would consider behaving otherwise as a bug.

Implementations usually don't throw an error but just assume something when the TZ designator is missing, which results in just different meanings. Needless to say that doesn't make the situation any better.

[abalkin]

Do I understand correctly that the request is to append '+00:00' to the result of dt.isoformat() when dt is naive? If so, -1. Python's datetime module does not dictate how naive datetime instances should be interpreted. UTC by default and local by default are both valid choices, but local by default is often preferable. There are at least two reasons for that:

1. Local time is the "naïve" time. Using UTC implies certain amount of sophistication.

2. Interpreting naive times as UTC is unnecessary because it is very easy to create aware instances with tzinfo=timezone.utc.

When communicating with javascript and in general when writing software for the Internet, I recommend using aware datetime instances. For example,

>>> from datetime import *
>>> datetime.now(timezone.utc).isoformat()
'2015-01-27T18:27:33.216857+00:00'

[mirkovogt]

from datetime import *
In [4]: datetime.utcnow().isoformat()
Out[4]: '2015-01-27T18:51:18.332566'

When using utcnow() e.g. I would expect the result definitely being marked as UTC.

[abalkin]

I highly recommend always specifying the timezone and would consider behaving otherwise as a bug.

I agree, and the datetime module lets you do that already:

>>> dt = datetime.now(timezone.utc)
>>> dt.isoformat()
'2015-01-27T18:53:40.380075+00:00'

or if you prefer local timezone,

>>> dt.astimezone().isoformat()
'2015-01-27T13:53:40.380075-05:00'

[abalkin]

When using utcnow() e.g. I would expect the result definitely being marked as UTC.

Don't use utcnow(). This is a leftover from the times when there was no timezone support in datetime.

The documentation for utcnow [1] already points you in the right direction, but we can consider formally deprecating it together with utcfromtimestamp.

[1] https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow

[mirkovogt]

I never said there is no way to result in an ISO 8601 string with UTC stated explicitly.

I showed a case where I think it is correct to assume UTC is stated ( e.g. utcnow()), however the result of isoformat() doesn't do so.

[abalkin]

What is your specific proposal?

As I explained, we cannot assume that naive timezone instances are in UTC because while sometimes they are (as in datetime.utcnow()), more often they are not (as in datetime.now()). So changing dt.isoformat() when dt is naive is wrong.

Another alternative would be to return aware instances from utcnow(), but that would break a lot of code.