Use request culture to deserialize JSON body

[martincostello]

PR Title

Add support for reading localized parsing of dates etc. in JSON model binding.

PR Description

Adds a new ReadJsonWithRequestCulture option to support deserializing JSON using the current HTTP request's culture when using the Newtonsoft.Json input formatter with MVC as suggested by #9994 (comment).

Addresses #9994

[davidfowl]

Needs an API proposal.

[martincostello]

#31334

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[pranavkm]

Perhaps this might be a better name if this worked for both input and output formatting?

Suggested change

	public bool ReadJsonWithRequestCulture { get; set; }
	public bool UseCurrentCulture { get; set; }

@martincostello can this also use the culture for output formatting? Seems weird it only works for reading, but not for writing.

[martincostello]

Yep that makes sense. Initially I just went down the route outlined in the initial issue, but I agree it would be better to have it be bi-directional.

I'll go with that suggested name for now and look at having the output formatter use it too.

[martincostello]

So from playing around with this locally, the serializer always writes in ISO format for DateTime values (or whatever is configured by the JsonSerializerSettings, e.g. the DateFormatString property).

Setting the writer/serializer to use the current culture has no effect on this and I'm not sure there's a sensible default to overwrite it for or that it's a good idea to special-case for DateTime/DateTimeOffset.

I'd also have to introduce a new constructor (or make a breaking change) to allow the MvcNewtonsoftJsonOptions to be passed into the output formatter to observe the value of the option to know if to set the culture or not.

Thoughts on best route forward?

[davidfowl]

cc @JamesNK in case he has thoughts

[JamesNK]

I think the main place culture is used with Newtonsoft.Json is when deserializing strings into .NET types.

For example:

{"Amount": "1.0"}

public class Product
{
    public decimal Amount { get; set; }
}

By default the culture is InvariantCulture. Changing the culture can be used in apps that want to allow strings like "1,0" (seems to be a European thing) to successfully convert to a decimal/double/float.

[halter73]

Semi-related to this is how we want to handle culture for simple minimal action parameters (#32377). First we need to default to InvariantCulture, but I think we might want a way to configure this.

[ghost]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[pranavkm]

Thanks for the PR!