First-class support for enforcing full RFC 3339 date-time (mandatory timezone)

RFC 3339 is the standard date/time format used by most popular JSON protocol tools today:

• JSON Schema date-time
• OpenAPI dateTime

If you look closely however, the date-time ABNF definition in that standard makes the timezone mandatory.

Despite that, JSON deserialization&validation, as offered by most out-of-the-box platforms using Newtonsoft JSON, such as ASP.NET Core, allow timezoneless (so, invalid) date-time values just fine, without informing the client of the problem.

Although there can be use cases where local time is desired (say, flight arrival time at destination, without having to know the timezone offset at that date, as providing this would require complex political knowledge not essential to solving the problem), in a great number of cases allowing the lack of timezone information is undesired, because it is unclear what the local time is supposed to be (browser clients can be in any timezone).

In fact, from my experience, sending a ‘timezoneless’ value will most often be a sign of a bug in the client (someone forgetting to use a proper UTC backed value or forgot to apply correct formatting), while the server accepting such a value will be a bug on the server - insufficient validation. Both of them combined will inevitably lead to a hard-to-spot data corruption. I really feel the library should allow, if not even encourage a design that prevents these common pitfalls, while it currently makes it ‘extremely difficult’, as one StackOverflow user stated.

I understand that it would be a breaking change to just make it the new default, but I feel this library should at least offer a way to enable it, perhaps as a SerializeDateTimeZoneHandling option.

When adopting this though, there would also need to be a consideration for the other DateTime-backed format, the date, which, in turn, doesn’t have the timezone indicator (but strictly speaking should also report invalidity for a value with the time segment). I would think that the easiest-to-use way would be using an attribute on the member, to tell one from another.

Context trivia: I only raised this here after mistakenly assuming it’s OpenAPI’s problem

[zlamma]

Thanks for considering.

Just one question for the general public that are trying to address the problem (e.g. the NSwag guys here - which, BTW, seem to be finding the converter approach still leaving certain use cases problematic).

So, in order to allow addressing this easily in any frameworks based on the JSON SChema or OpenAPI, would you consider a pull request to addresses any of this?

(I’m not sure I will find time myself, but it’d be good to know that the doors are open for a comprehensive fix)

[JamesNK]

If you really desire an error rather than automatically converting then I suggest you write a date time converter that will error when the given DateTime isn’t valid or the incoming date string is isn’t valid.

If there is more demand in the future I’ll consider adding it as a core feature but for now Json.NET serializes and deserializes as ISO 8601, not the RFC.