date-time is not formatted correctly

Open

#841 opened on Aug 23, 2023 4 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 2/5
Estimated time: 1-3 hours
Newbie friendliness: 42/100

Issue type: Bug
Clarity: Mostly clear
Activity status: Stale
Tech stack: openapi, python
Domain: api

Research direction

Start by locating the generated client request serialization that handles datetime.datetime values and calls isoformat(). Compare its output with the RFC3339/OpenAPI examples in the issue, then run or add coverage for date-time query parameters. Done means generated timestamps are accepted as compliant date-time values by the reported server.

Written by the indexing model from the issue text.

Description

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.

Dominant language: Python
Stars: 2k
Forks: 293
Avg merge: 34m
Merged PRs (30d): 1

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

[essnmx] Fix typo in NXLauetof application definition Open

essnmx good first issue

Difficulty 1/5 Under an hour Newbie friendliness 95/100

scipp/ess#760 · Opened Sep 23, 2026
[Feature] 奇物选择添加优先级 Open

Difficulty 2/5 1-3 hours Newbie friendliness 65/100

syfoud/Simulated_Scepter#174 · Opened Sep 23, 2026
garak adapter grades a NaN detector score as PASS Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

Giskard-AI/giskard-oss#2840 · 1 comment · Opened Sep 23, 2026
A claim comment carrying the issue number is silently declined while the workflow reports success Open

area: repo bug perceived difficulty: 2

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

Nitjsefnie-Harness-Commons/daedalus#926 · Opened Sep 23, 2026
`IOCExtractor` always fails: `ioc_analyzer.build()` takes 1 argument but the agent dispatcher passes 2 Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

yeti-platform/yeti#1380 · Opened Sep 23, 2026

More Python issues