You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To reflect these changes, C# tests are also altered in #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.
The text was updated successfully, but these errors were encountered:
In ScottLogic/openapi-forge#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 ScottLogic/openapi-forge#187).
To reflect these changes, C# tests are also altered in #50. However, these changes are applied on a surface level where both
date
anddate-time
strings are still represented byDateTime
type in C#. In the mentioned PR, the tests conditionally convert the testing property intoDateOnly
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 theDateOnly
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.
The text was updated successfully, but these errors were encountered: