You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Additional context
Client code generated using openapi-python-client version 0.15.1 parses datetime.datetime objects and uses .isoformat() function to convert these to strings. This produces timestamp strings non-compliant with OpenAPI spec (https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#data-types). According to spec timestamps should look like this: 2023-08-23T13:26:16Z
Instead they look like this: 2023-08-23T12:26:16.979067
I have a server that rejects these as invalid timestamps. I can patch the client manually after generation, but I thought it would be beneficial to submit a bug report.
The text was updated successfully, but these errors were encountered:
If I understand correctly, the only thing isoformat needs in order to be RFC3339-compliant is a timezone—so really what we need is a way to represent datetimes that are timezone-aware, right? I don't know of a way to do that with any builtin types, unfortunately, and building functionality to validate this at runtime won't be a much different experience than having the server respond with an error 🤔.
The "easy" solution is to have users of the generator always pass timezone-aware datetimes 😅. However teaching consumers of the generated clients to do that isn't ideal.
We could create a new DateTime or similar class to use in place of the built-in one, which always requires passing in tzinfo, that feels heavy-handed, though.
Describe the bug
OpenAPI date-time fields are generated using
datetime.datetime.isoformat
and don't comply with OpenAPI spec / RFC3339OpenAPI Spec File
Desktop:
Additional context
Client code generated using openapi-python-client version 0.15.1 parses
datetime.datetime
objects and uses.isoformat()
function to convert these to strings. This produces timestamp strings non-compliant with OpenAPI spec (https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#data-types). According to spec timestamps should look like this:2023-08-23T13:26:16Z
Instead they look like this:
2023-08-23T12:26:16.979067
I have a server that rejects these as invalid timestamps. I can patch the client manually after generation, but I thought it would be beneficial to submit a bug report.
The text was updated successfully, but these errors were encountered: