To reflect these changes, C# tests are also altered in https://github.com/ScottLogic/openapi-forge-csharp/pull/50. However, these changes are applied on a surface level where both date and date-time strings are still represented by DateTime type in C#. In the mentioned PR, the tests conditionally convert the testing property into DateOnly on runtime in an ad-hoc way.
For context, C# introduced DateOnly type [1] in dotnet6. However, they haven't introduced the serialisation/deserialisation for this type until dotnet7 [2]. Since the test project is on dotnet6 (which is a LTS release), it is not possible to use the DateOnly type on generated code.
To address the mentioned problem, one option is to write custom ser/deser methods which can be undesirable for generated code structures. A more viable second option to bring the project to dotnet >=7 at a later stage to eliminate this limitation. The testing of date/datetime can be streamlined from that point onwards.
ColinEberhardt
commented
1 year ago
In https://github.com/ScottLogic/openapi-forge/issues/185, it is established that swagger distinguishes date and date-time types. The necessary changes to address this has been made in the main repo (see https://github.com/ScottLogic/openapi-forge/pull/187).
To reflect these changes, C# tests are also altered in https://github.com/ScottLogic/openapi-forge-csharp/pull/50. However, these changes are applied on a surface level where both
dateanddate-timestrings are still represented byDateTimetype in C#. In the mentioned PR, the tests conditionally convert the testing property intoDateOnlyon runtime in an ad-hoc way.For context, C# introduced
DateOnlytype [1] in dotnet6. However, they haven't introduced the serialisation/deserialisation for this type until dotnet7 [2]. Since the test project is on dotnet6 (which is a LTS release), it is not possible to use theDateOnlytype on generated code.To address the mentioned problem, one option is to write custom ser/deser methods which can be undesirable for generated code structures. A more viable second option to bring the project to dotnet >=7 at a later stage to eliminate this limitation. The testing of date/datetime can be streamlined from that point onwards.