Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG][RUST] chrono date-time path/query/header params are not serialized as RFC 3339

Open Beginner friendly
  • Is something wrong?
#25,297 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@teovillanueva is already working on this.

Since Oct 17, 2026.

  • #25298 by @teovillanueva — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
openapi, rust
Domain
developer-experience, tooling

Research direction

Start with the Rust templates that generate src/apis/default_api.rs for the rust generator and the reqwest, reqwest-trait, and hyper libraries. Find the path, query, and header serialization sites where chrono DateTime values currently use Display or .to_string(), while leaving NaiveDate unchanged. Generate the client from the provided spec and verify those three parameter locations emit RFC 3339 values; existing Rust generator tests should cover the regression.

Written by the indexing model from the issue text.

Description

Bug Report Checklist
  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
Description

With the rust client generator and useChrono=true (the default), format: date-time parameters are typed chrono::DateTime<chrono::FixedOffset>. Path, query and header params of that type are turned into strings with Display (.to_string() / format!), and chrono's Display is not RFC 3339:

GET /orders/2026-01-02%2003:04:05%20+00:00?createdAfter=2026-01-02+03%3A04%3A05+%2B00%3A00
x-request-time: 2026-01-02 03:04:05 +00:00

Expected (RFC 3339, the same format serde uses for these values in bodies):

GET /orders/2026-01-02T03:04:05+00:00?createdAfter=2026-01-02T03%3A04%3A05%2B00%3A00
x-request-time: 2026-01-02T03:04:05+00:00

Servers that strictly parse date-time reject the request. This affects the reqwest, reqwest-trait and hyper libraries. format: date (chrono::NaiveDate) is not affected, because its Display is already YYYY-MM-DD.

openapi-generator version

master (7.27.0-SNAPSHOT). Not a regression: it has been this way since chrono support was added.

OpenAPI declaration file content or url
openapi: 3.0.3
info:
  title: date-time params
  version: 1.0.0
paths:
  /orders/{since}:
    get:
      operationId: listOrders
      parameters:
        - name: since
          in: path
          required: true
          schema:
            type: string
            format: date-time
        - name: createdAfter
          in: query
          required: true
          schema:
            type: string
            format: date-time
        - name: X-Request-Time
          in: header
          required: false
          schema:
            type: string
            format: date-time
      responses:
        '204':
          description: No content
Generation Details
java -jar openapi-generator-cli.jar generate -g rust --library reqwest -i spec.yaml -o out

The same happens with --library reqwest-trait and --library hyper.

Steps to reproduce
  1. Generate the client from the spec above.
  2. Look at src/apis/default_api.rs: since=p_path_since, &p_query_created_after.to_string(), .header("X-Request-Time", param_value.to_string()).
  3. Call list_orders with DateTime::parse_from_rfc3339("2026-01-02T03:04:05Z") and inspect the request: the values are sent as 2026-01-02 03:04:05 +00:00.
Related issues/PRs

#23451 (added chrono support to the rust client)

Suggest a fix

For chrono DateTime path, query and header params, use .to_rfc3339() instead of Display.

Dominant language
Java
Stars
26.8k
Forks
7.7k
Avg merge
1d 14h
Merged PRs (30d)
145

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

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

More from OpenAPITools/openapi-generator

All issues in OpenAPITools/openapi-generator

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.