CenterEdge / Yardarm

OpenAPI 3 SDK Generator for C#
Apache License 2.0
46 stars 6 forks source link

DateTime becoming DateTimeOffset #231

Closed tagz97 closed 9 months ago

tagz97 commented 9 months ago

Hiya!

Package Generated with Yardarm.CommandLine targeting .NET 8 (Release 0.4.1) with argument: generate -i ACOrderAPI.json -n ACOrderAPI -v 1.1 -f net8.0 --nupkg NuGets/ -x Yardarm.NewtonsoftJson Yardarm.MicrosoftExtensionsHttp

I have a slight issue where a DateTime is being made into a DateTimeOffset when being serialised and this is bricking my API integration as the data contract is DateTime and will not be changing.

"parameters": [
                    {
                        "name": "deliveryDate",
                        "in": "path",
                        "description": "Format - date-time (as date-time in RFC3339). The specific delivery date",
                        "required": true,
                        "schema": {
                            "type": "string",
                            "format": "date-time"
                        }
                    }
],

Output:

//
// Summary:
//     Format - date-time (as date-time in RFC3339). The specific delivery date
[Required]
public DateTimeOffset DeliveryDate { get; set; }

Is there a possible work around for this or do I need to use different CommandLine arguments?

brantburnett commented 9 months ago

The date-time format, per the OpenAPI specification https://swagger.io/docs/specification/data-models/data-types/, should follow RFC3339 section 5.6 https://datatracker.ietf.org/doc/html/rfc3339#section-5.6. This format is allowed to include a time zone, so DateTimeOffset is generally the most appropriate type to match to that.

Is your problem on the C# side, meaning you want a DateTime instead of DateTimeOffset internally? Or is the problem that the API you are calling isn't quite implemented correctly and isn't accepting the time zone being sent (or isn't returning a value that includes it)?

tagz97 commented 9 months ago

I think the problem might then be API side as if a time zone is included, the request bounces as it cannot find the endpoint. If the time zone is excluded then the request can be processed.

I think this is something I will have to take away to see if I can get it to work my side either by middleware to adjust format or do some transforming in the gateway to handle it because I cannot really adjust the DateTime to DateTimeOffset.

I'm happy to close this off as if its to follow RFC3339 then its not a Yardarm issue and will have to be something my side. Thanks for the clarification! 👍

brantburnett commented 9 months ago

You can certainly adjust the generated SDK by using an extension, Yardarm is designed to be extensible. This could be used to switch the DateTimeOffset to a DateTime and override the default behavior. It's just not something I'm eager to bake into the base package.

You could inherit from StringSchemaGenerator and override this behavior: https://github.com/CenterEdge/Yardarm/blob/ac6c2dbc13d297cb768ce38f80dfe36426900807/src/main/Yardarm/Generation/Schema/StringSchemaGenerator.cs#L28

Then inherit from DefaultSchemaGeneratorFactory and swap out the string behavior to be the custom generator: https://github.com/CenterEdge/Yardarm/blob/ac6c2dbc13d297cb768ce38f80dfe36426900807/src/main/Yardarm/Generation/Schema/DefaultSchemaGeneratorFactory.cs#L32

Let me know if you need any assistance with that.

tagz97 commented 9 months ago

@brantburnett I had tried that but I forgot to override previously so following your instructions, this has worked perfectly thank you ❤️