Skip to content

date-time is not formatted correctly #841

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
a-gertner opened this issue Aug 23, 2023 · 4 comments · May be fixed by #1213
Open

date-time is not formatted correctly #841

a-gertner opened this issue Aug 23, 2023 · 4 comments · May be fixed by #1213

Comments

@a-gertner
Copy link

a-gertner commented Aug 23, 2023 •
edited
Loading

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.
@dbanty
Copy link
Collaborator

dbanty commented Sep 3, 2023

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?

@jeferro
Copy link

jeferro commented Jan 27, 2025

The problem is that method datetime.now() creates a new datetime without timezone. To solve this, I create new datetime in UTC timezone:

datetime.now(timezone.utc)

@iloveitaly
Copy link

Running into the exact same issue here. @a-gertner Did you discover a workaround here that didn't involve patching the client?

@a-gertner
Copy link
Author

Running into the exact same issue here. @a-gertner Did you discover a workaround here that didn't involve patching the client?

No, I only needed it for a one-time use, so I patched the client.

@iloveitaly iloveitaly linked a pull request Mar 4, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: remove milliseconds from isoformat iloveitaly/openapi-python-client
4 participants
@iloveitaly @jeferro @dbanty @a-gertner