date-time is not formatted correctly
a-gertner opened this issue · comments
Describe the bug
OpenAPI date-time fields are generated using datetime.datetime.isoformat
and don't comply with OpenAPI spec / RFC3339
OpenAPI Spec File
/api/example:
get:
tags:
- "example"
operationId: example-get
summary: "summary removed"
description: ""
parameters:
- in: query
name: "start"
description: "desciption removed"
required: true
schema:
type: string
format: date-time
example: '2020-07-21T17:32:28Z'
- in: query
name: "end"
description: "desciption removed"
required: true
schema:
type: string
format: date-time
example: '2020-07-21T17:32:28Z'
Desktop:
- OS: Windows 11
- Python Version: 3.9.13
- openapi-python-client version 0.15.1
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.
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.
Any ideas on a more elegant solution?