[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
New submission from Mirko Vogt: 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 -- messages: 234829 nosy: mirkovogt priority: normal severity: normal status: open title: datetime.isoformat() -> explicitly mark UTC string as such type: behavior ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: 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. -- ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: 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. -- ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: 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. -- type: enhancement -> behavior ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: 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. -- ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: I got that - so marking utcnow() as deprecated seems like a good idea. But it's not just about utcnow() but also now(). now() also doesn't return any timezone stated by default - which I would still consider as a bug. However making now() require a TZ being specified would probably also break a lot of code. But then, using function called isoformat() - on whatever object, naive or not - I'd expect a timezone being specified - since that's what I finally think the ISO-standard actually says. I see that my initial proposal doesn't work out, but I'm still not happy with the current situation I'm however also not sure how to change properly without breaking existing code using those functions. -- ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: Just to clarify my problem - then I'll just happily use datetime.now(tzutc()).isoformat() - There is datetime.now() which is supposed to be used (no utcnow() anymore) - datetime.now() might return a naive object, when no TZ is specified - *However* also the naive variant implements the class isoformat() which is described as "Return a string representing the date in ISO 8601 format" - ISO 8601 can and should be understood such as the TZ-designator is required (I think we agreed on that). - However isoformat() called on a naive object returns a string with no TZ designator I would at least suggesting adding a note for isoformat() about being called on naive datetime objects. -- ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() -> explicitly mark UTC string as such
Mirko Vogt added the comment: The proper response to that comment probably is: It's called ISO8601 and not RFC8601. And unfortunately ISO stands for "International Standard". -- ___ Python tracker <http://bugs.python.org/issue23332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
