string with format `date` is generated as `DateTimeOffset` but should be `DateOnly`

[kMutagene]

Description

Hi there, thanks for this awesome library.

I have a ASP.NET core API that uses the DateOnly type for a field, which looks like this in the generated OpenAPI doc:

"ReleaseDate": {
    "type": "string",
    "format": "date"
}

From the docs of the OpenAPI spec, "format": "date" indicates:

full-date notation as defined by RFC 3339, section 5.6, for example, 2017-07-21

But the OpenAPI provider sets the field type as DateTimeOffset in the generated spec. This only works when parsing responses, but fails when posting data with this field to the API, because it cannot parse the provided string to DateOnly:

RequestBody: {"ReleaseDate":"2024-02-22T14:30:01.8849759+01:00"}
Microsoft.AspNetCore.Http.BadHttpRequestException: Failed to read parameter "d" from the request body as JSON.
---> System.Text.Json.JsonException: The JSON value could not be converted to System.DateOnly. Path: $.ReleaseDate | LineNumber: 0 | BytePositionInLine: 154.

Is this happening because you also want to target netstandard2.0? IIRC DateOnly is available starting with net6.0.

Affected Type Providers

• SwaggerClientProvider
• OpenApiClientProvider (only used this one as my schema is OpenAPI v3.0)

Related information

• Operating system: Win 11
• .NET Runtime, CoreCLR or Mono Version: .NET 8

[Thorium]

You have option to customize the serialization
https://fsprojects.github.io/SwaggerProvider/#/Customization#serialization

[kMutagene]

@Thorium thanks - that feels more like a workaround though, since the client generated by the provider creates API calls that are wrong according to the schema.

I have taken a look at the C# client that gets generated by NSwag for the same schema, and while they also use DateTimeOffset (which makes sense from a backwards compatibility perspective i guess), the client contains a customized serialization setting from the get-go:

    [System.CodeDom.Compiler.GeneratedCode("NJsonSchema", "14.0.3.0 (NJsonSchema v11.0.0.0 (Newtonsoft.Json v13.0.0.0))")]
    internal class DateFormatConverter : Newtonsoft.Json.Converters.IsoDateTimeConverter
    {
        public DateFormatConverter()
        {
            DateTimeFormat = "yyyy-MM-dd";
        }
    }

which then decorates the fields that are marked via format: date. If you could point in the right direction in the source code, i would be happy to try to file a small PR that adds something similar automatically for these cases.

[sergey-tihon]

Here is the place where we define a type for date-time string for OpenApiClientProvider
https://github.com/fsprojects/SwaggerProvider/blob/master/src/SwaggerProvider.DesignTime/v3/DefinitionCompiler.fs#L412

Here is the code that add a custom attribute to the generated property
https://github.com/fsprojects/SwaggerProvider/blob/master/src/SwaggerProvider.DesignTime/v3/DefinitionCompiler.fs#L205-L208

[Thorium]

The offset (with time-zone) is a bit weird guy with "date" as there is no time-zone conversions and SwaggerProvider is a server-side tool where you'd expect everything to be UTC. If you want, you could do line 411 conditional compilation something like

| "date" ->
#if NETSTANDARD2.1
    typeof<DateOnly>
#else
    typeof<DateTime>
#endif

...but that could make the maintenance more complex than the real gain. Because the end-user may compile the same SwaggerProvider using source-code to multiple targets too, and then they would have to also do conditional compilations.

[sergey-tihon]

Type inference code (DefinitionCompiler.fs) runs in design-time, so netstandard2.1 assembly may be loaded by compiler/ide instead of loading netstandard2.0 and then TP will always emit DateOnly no matter what the target runtime for of the project that uses SwaggerProvider.

I am not sure if it is possible to conditionally check the target compilation runtime for the TP design-time component.

[Thorium]

oh right it goes straight to the problem where VS Code runs on netstandard2.1 and VS full runs on netstandard 2.0

[MichaelMay81]

What if there were a switch for the Provider where the user can decide if Date is a DateTimeOffset or a DateOnly?
Default would be DateTimeOffset to not break legacy code and in the documentation it must be stated, that this only works for .Net 6 and above...

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for raising this, and thanks to @kMutagene for PR #241 and to @Numpsy for the recent investigation note.

Current State

In DefinitionCompiler.fs (line 499–500), both format: date and format: date-time fields are mapped to DateTimeOffset:

| HasFlag JsonSchemaType.String, "date"
| HasFlag JsonSchemaType.String, "date-time" -> typeof(DateTimeOffset)

This means a JSON property declared as format: date (which should round-trip as "2024-01-15") currently serializes/deserializes as a full DateTimeOffset ISO 8601 string (e.g. "2024-01-15T00:00:00+00:00"), which is wrong per the OpenAPI spec.

What PR #241 Does

PR #241 adds a DateTimeOffsetFullDateConverter : JsonConverter(DateTimeOffset) that writes dates as yyyy-MM-dd and attaches it as a [(JsonConverter(...))] attribute to properties with format: date. This is the right approach — keeps DateTimeOffset as the .NET type for backwards compatibility but fixes the serialization format.

What Needs Fixing in the PR

The PR needs a couple of updates to work with the current codebase:

1. API mismatch: The PR checks schemaObj.Type as a string ("string"), but the current Microsoft.OpenApi 2.x API uses JsonSchemaType (a flags enum). The check in the property-generation loop should be against propSchema (the individual property's schema), not schemaObj (the parent object schema), and should use the enum:

   if propSchema.Type.HasValue
      && propSchema.Type.Value.HasFlag(JsonSchemaType.String)
      && propSchema.Format = "date" then
       pProp.AddCustomAttribute(RuntimeHelpers.getDateTimeOffsetFullDateConverterAttribute())

2. Tests missing: The maintainer has already pointed to the right place — extend SpecialCasesControllers.fs with an endpoint that has a format: date property, then add a test in Swashbuckle.SpecialCasesControllers.Tests.fs. @Numpsy's Dec 2025 comment shows that a DateOnly-based controller can expose the bug, but the fix targets DateTimeOffset serialization, so a DateTimeOffset (or DateTime) property with explicit format: date in the Swagger annotation would be the cleanest repro.

Suggested Path Forward

If @kMutagene or anyone else wants to push this PR forward:

1. Fix the propSchema.Type/propSchema.Format check as above
2. Add a Swashbuckle controller endpoint with a DTO that has a System.DateTimeOffset property annotated with [(JsonPropertyName("date_field"))] and the schema's format: date, plus a corresponding provider test
3. Run dotnet fake build -t RunTests to verify

The converter logic itself looks correct and the RuntimeHelpers.getDateTimeOffsetFullDateConverterAttribute() pattern matches the existing getPropertyNameAttribute pattern in the codebase.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f