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

Alexander Belopolsky added the comment: The premise of this issue is factually incorrect: > ISO 8601, which states that, if no timezone is specified, > the string is supposed to be interpreted as UTC implicitly. The opposite is true: "If no UTC relation information is given with a time represe

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

Alexander Belopolsky added the comment: > RFCs are just RFCs and not standards RFCs have a standards track which includes steps such as "Proposed Standard", "Draft Standard", and "Internet Standard". Once they become Internet Standards, they get an additional designation as STD. For example,

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

R. David Murray added the comment: mirabilos was referring to Alexander's reference to RFCs that advise against using 'Z'. RFC are standards once they become formally accepted as such, and often they become de-facto standards before formal acceptance. Given that the method is supposedly con

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

Mark Lawrence added the comment: I'm a British citizen and I've never once heard the term "British Winter Time", so where does it come from? -- nosy: +BreamoreBoy ___ Python tracker ___

[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

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

mirabilos added the comment: Hm, RFCs are just RFCs and not standards, they can recommend whatever they want, and they can (and do) contradict each other. I’ve seen things (mostly related to eMail and PIM synchronisation) that require ‘Z’ for UTC proper. Additionally, +00:00 can be UTC, but i

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

Alexander Belopolsky added the comment: > ISO 8601 can and should be understood such as the TZ-designator is required > (I think we agreed on that). No. There is no such requirement in ISO 8601 as far as I remember. -- ___ Python tracker

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

Alexander Belopolsky added the comment: Why do you call it a bug? Specifying UTC as +00:00 is perfectly valid by ISO 8601 and some RFCs that are based on the ISO standard recommend against using the Z code. -- ___ Python tracker

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

mirabilos added the comment: There’s another minor bug here: UTC should append “Z”, not “+00:00”, which other timezones at that offset can do. Agreed about no timezone being “floating” time in many instances, e.g. the iCalendar format uses that. -- nosy: +mirabilos __

[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 naiv

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

Alexander Belopolsky added the comment: Mirko, You may want to review #9527. I don't think we left any stone unturned in this area. -- ___ Python tracker ___ _

[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 specifi

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

Alexander Belopolsky added the comment: s/timezone instances/datetime instances/ -- ___ Python tracker ___ ___ Python-bugs-list mailin

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

Alexander Belopolsky added the comment: 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 n

[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. -- ___

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

Alexander Belopolsky added the comment: > 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 righ

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

Alexander Belopolsky added the comment: > 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

[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 ___ P

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

Alexander Belopolsky added the comment: 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 def

[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 "

[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

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

R. David Murray added the comment: I wonder what the chances are that doing that would break other software with the opposite assumption (an assumption based on past Python behavior). -- nosy: +belopolsky, r.david.murray ___ Python tracker

[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 sup