DateOnly and TimeOnly are displayed as complex objects in open-api schemas rather simple string

[rafikiassumani-msft]

Describe the bug

DateOnly and TimeOnly are being displayed as complex objects in open api schemas for Minimal API endpoints rather than being treated as simple strings. It will make sense for open api to treat them as string -$date-only and string -$time-only

app.MapGet("/events", (DateOnly dateOnly, TimeOnly timeonly) => $" date and time values ... ")

Exceptions (if any)

  ### Further technical details
  .NET SDK (reflecting any global.json):
   Version:   6.0.100-rc.2.21465.13
   Commit:    0d1cdfa6a0
  
  Runtime Environment:
   OS Name:     Windows
   OS Version:  10.0.19043
   OS Platform: Windows
   RID:         win10-x64
   Base Path:   C:\Program Files\dotnet\sdk\6.0.100-rc.2.21465.13\

[rafikiassumani-msft]

This may need a change in Swashbuckle and N-Swag for these new primitives.

[captainsafia]

Looked into this briefly. Draft 07 of the JSON schema adds support for the date and time formats on strings (ref). Until that is officially incorporated into the spec, it probably makes sense to keep this as an object.

[DamianEdwards]

Looks like this doesn't happen now in .NET 7, but it's still not perfect. It's now projected as a string (good!) but with the "date-time" format (bad!). Seems Swagger does actually support "date" as a format now so we should get Swashbuckle updated to map DateOnly to "string" formatted as "date". Swashbuckle has an issue filed for this already.

[DamianEdwards]

Workaround by adding a type mapping to Swashbuckle until they fix their defaults:

builder.Services.AddSwaggerGen(
    c.MapType<DateOnly>(() => new OpenApiSchema
    {
        Type = "string",
        Format = "date"
    });
);

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

@rafikiassumani-msft I think we should close this in favor of domaindrivendev/Swashbuckle.AspNetCore#2319. I already have a PR out to fix it at domaindrivendev/Swashbuckle.AspNetCore#2480