[BUG][JAVA] Property defined as type `string` with format `date-time` accepts integers

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• 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?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

Actual behaviour
When defining a date property like so:

start_date:
    type: string
    format: date-time

integer values for start_date are accepted and treated as epoch seconds e.g. 1 becomes 1970-01-01T00:00:01Z in the resulting OffsetDateTime value.

Expected behaviour
Given the field has type string, my expectation would be that an integer value would be rejected e.g. some deserialization error like Cannot deserialize value of type date-timefrom Integer 1: not a validdate-time value.

I can see how the coercion from an integer value may be useful for some edge cases, but it seems counter intuitive that a type defined as string will happily accept an integer. In my specific use case I would like to prevent users from sending request bodies with dates defined as integers (it's simply not an expected use case for my API).

openapi-generator version

7.10.0, not a regression AFAIK

OpenAPI declaration file content or url

openapi: 3.0.0
info:
  title: Test
  version: v1
paths:
  /test:
    post:
      operationId: test
      requestBody:
        required: true
        description: Lorem ipsum
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/RequestBody'
      responses:
        201:
          description: Lorem ipsum
          content:
            application/json:
              schema:
                type: object
                properties:
                  foo:
                    type: string

components:
  schemas:
    RequestBody:
      properties:
        start_date:
          type: string
          format: date-time
          example: "2025-01-01T00:00:00Z"
        end_date:
          type: string
          format: date-time
          example: "2025-01-01T00:00:00Z"

Related issues/PRs

I wasn't able to find existing issues relating to this topic.

Start by generating the Java code from the supplied OpenAPI declaration and trace how the integer value for start_date is deserialized into OffsetDateTime. Add a regression test covering an integer for the string date-time property; done means that input is rejected with a deserialization error while valid date-time strings still work.