Non IS0-8601 compliant date time format

[bmarkovic17]

HI all,

I have a question regarding using Kiota on an OpenAPI specification that has the following excerpt:

...
"startDateTime": {
    "type": "string",
    "format": "yyyy-MM-dd'T'HH:mm:ss.SSS[xxx]"
}
...

Since the date time format is not ISO-8601 compliant, Kiota creates a string property with the following warning:

The format yyyy-MM-dd'T'HH:mm:ss.SSS[xxx] is not supported by Kiota for the type string and the string type will be used.

It is a 3rd party API and unfortunately I can't change anything on the specification part, but I'm wondering if I can do something on my end to enforce a DateTimeOffset property instead of a string one.

Thank you for the help.

[baywet]

Hi @bmarkovic17
Thanks for using kiota and for reaching out.
For your information, here is the format registry for OAS
You can:

• make a local copy of the description, add it to your repository, change the format to "date-time".
• try to convince the publisher to publish an update to the description.
• keep the property as is, and use DateTimeOffset manually to parse, manipulate, serialize the value over the generated property.

We've been talking about adding support for OpenAPI overlays lately to support those kind of scenarios, let us know if this is something you'd be interested in.

[baywet]

additionally this "format" could be moved to the "pattern" field instead. https://json-schema.org/draft/2020-12/json-schema-validation#name-pattern

[bmarkovic17]

Thank you @baywet for the quick reply.

Yeah, I currently have a local copy that I altered to have a DateTimeOffset property, but that isn't ideal in the long term as the description will have changes, so I'm gonna suggest the publisher to move it to the pattern field as you suggested. In case that fails, I'd be interested in OpenAPI overlays, can you tell me a bit more how would they work?

[baywet]

Here is the issue that requests it (it's in the library kiota uses to parse the descriptions) microsoft/OpenAPI.NET#615

[0x090909]

Im having a similar issue

[0x090909]

#4118 (reply in thread)

ERRO[0000] parsing time "2024-02-09T12:14:04.000+0000" as "2006-01-02T15:04:05Z07:00": cannot parse "+0000" as "Z07:00"

[bmarkovic17]

I'm guessing that the issue here is that a property is marked with a date-time format but the actual value that is coming in, isn't formated as such.

You can make the property a string and then manually parse it or maybe implement a custom serializer/deserializer that will know how to transform these properties to DateTimeOffset.

If I'm wrong please provide more details on what is happening and I can take a look.

[svrooij]

@bmarkovic17 it seems like you're getting the hang of it. With this answer that looks like the solution above.

[0x090909]

Yes you're correct I thought exactly as you and It worked, but I have to parse the string later.

…

On Sun, 11 Feb 2024 at 06:25, Boris Marković ***@***.***> wrote: I'm guessing that the issue here is that a property is marked with a date-time format but the actual value that is coming in, isn't formated as such. You can make the property a string and then manually parse it or maybe implement a custom serializer/deserializer that will know how to transform these properties to DateTimeOffset. If I'm wrong please provide more details on what is happening and I can take a look. — Reply to this email directly, view it on GitHub <#4118 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEBESU5X2PSDROCB6NXPTPDYTBI3VAVCNFSM6AAAAABCWWWSCSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DIMZRGA3DI> . You are receiving this because you commented.Message ID: ***@***.***>