extension string properties being converted to date/times

[msoliver]

If I have an Open API document with an extension JSON block like so:

"x-myextension-foo" : { "myvalue": "1:1" }

the string value "1:1" is being parsed as a date time because of the following code:

        if (((OpenApiString)openApiAny).IsExplicit())
        {
            // More narrow type detection for explicit strings, only check types that are passed as strings
            if (schema == null)
            {
                if (DateTimeOffset.TryParse(value, CultureInfo.InvariantCulture, DateTimeStyles.None, out var dateTimeValue))
                {
                    return new OpenApiDateTime(dateTimeValue);
                }
            }
            else ...

There doesn't seem to be any way to avoid this. Perhaps modify this code to not use DateTimeStyles.None since it's so greedy. Or provide a way to supply custom parsers to the Open API reader.

[darrelmiller]

Thanks for reporting this. Looking at the available datetime styles here it is not clear to me what would be the most compatible option.

I actually think we made a mistake by trying to infer native types at all. It has caused a number of issues so far. I think in a future release we are simply going to leave strings as strings and then allow the application developer to do explicit transformation.
I'm curious, if you register a strongly typed myextension-foo parser is this still a problem? e.g. Like this https://github.com/microsoft/OpenAPI.NET/blob/vnext/test/Microsoft.OpenApi.Readers.Tests/TestCustomExtension.cs#L29

[msoliver]

Yep, still a problem. I tried that approach first before posting (using my own custom parser for my extension). It's still a problem because the data detail has already been parsed as a DateTime - the extension parser just gives me the ability to map it to my own C# extension class, but the data has already been converted...

What I would need is an interface that would allow me to write my own custom version of: GetSpecificOpenApiAny, or of course be able to syntactically tell the converter to ignore this property.

Of course, if a future release just does away w/ this inference code, that would solve it too! :)

[LeroyK]

I have been running into similar issues when trying to clone an OpenApiDocument by serializing it to json and deserializing. Example values would be converted to incorrect types, even numeric values that were deliberately serialized as string would become numeric (eg. "123" would be deserialized as a numeric value of 123).

I agree with @darrelmiller that inferring native types migth have been a mistake. Actually I think it should be removed or at least be made optional.

[darrelmiller]

@LeroyK Making it optional is a good idea. Making it a reader setting would actually be a good way that we can fix this behavior without making a breaking change.

[mikecowgill]

I just ran into this as well. In my extension, a semantic version string "3.1.2" is converted into a datetime. Adding the ability to disable the type inference would be great.

[darrelmiller]

I have pushed this out to the 1.4 milestone. I need to get 1.3 out. I am going to investigate creating a reader option in 1.4 to stop trying to infer types.

[MaggieKimani1]

Closing this as it has been fixed in v2 where we've pulled all rich typing out of this library because OpenAPI 3.1 uses native JSON Schema and it is limited to JSON types.