Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for model binding DateTime as UTC #24893

Merged
4 commits merged into from
Aug 18, 2020
Merged

Conversation

pranavkm
Copy link
Contributor

Fixes #11584

This change adds a model binder that produces UTC DateTime values by default. Prior to this change, model bound DateTime values used local times. However, this was inconsistent with JSON formatted values which produces DateTime of UTC kinds.

I'll add a migration note as a follow up with a code sample to revert to the previous behavior.

@ghost ghost added the area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates label Aug 13, 2020
@pranavkm pranavkm added this to the 5.0.0-rc1 milestone Aug 13, 2020
Copy link
Member

@dougbu dougbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/fyi tests still don't work in other time zones

@dougbu
Copy link
Member

dougbu commented Aug 14, 2020

Missed your latest commit but my other comments stand

* Cleanup unused exception code path, fix doc comments
* Clean up usage of variables
* Adjust logging to be consistent
@pranavkm
Copy link
Contributor Author

🆙 📅

1 similar comment
@pranavkm
Copy link
Contributor Author

🆙 📅

@pranavkm pranavkm added the api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews label Aug 14, 2020
@ghost
Copy link

ghost commented Aug 14, 2020

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.

Copy link
Member

@dougbu dougbu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :shipit:

var type = metadata.UnderlyingOrModelType;
try
{

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

else
{
// unreachable
throw new NotSupportedException();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This type is constructable right? So it isn't really unreachable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe because this uncommon? IDK, removed it because it didn't really add much value.

@@ -46,6 +46,8 @@ public Task BindModelAsync(ModelBindingContext bindingContext)
throw new ArgumentNullException(nameof(bindingContext));
}

_logger.AttemptingToBindModel(bindingContext);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need move the logging above the work in other binders?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of the ones that relied on the value provider, Simple type was the only outlier.

@@ -73,7 +72,7 @@ public Task BindModelAsync(ModelBindingContext bindingContext)
}
else if (type == typeof(float))
{
model = float.Parse(value, _supportedStyles, culture);
model = float.Parse(value, _supportedStyles, valueProviderResult.Culture);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any functional reason for inlining this or just code clarity?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pranavkm pranavkm added api-approved API was approved in API review, it can be implemented and removed api-ready-for-review API is ready for formal API review - https://github.com/dotnet/apireviews labels Aug 17, 2020
else
{
// unreachable
throw new NotSupportedException();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe because this uncommon? IDK, removed it because it didn't really add much value.

@ghost
Copy link

ghost commented Aug 17, 2020

Hello @pranavkm!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

/// </summary>
public class DateTimeModelBinderProvider : IModelBinderProvider
{
internal static readonly DateTimeStyles SupportedStyles = DateTimeStyles.AdjustToUniversal | DateTimeStyles.AllowWhiteSpaces;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be configurable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can create a binder provider that configures the model binder (it's constructable). It's the pattern we use for other types.

@pranavkm pranavkm changed the base branch from master to release/5.0 August 17, 2020 21:25
@ghost ghost merged commit 512a49c into release/5.0 Aug 18, 2020
@ghost ghost deleted the prkrishn/utc-datetime branch August 18, 2020 04:04
@augustoproiete
Copy link

I was bitten by this bug today on .NET Core 3.1.403. Is this going to be back-ported to a future 3.1.x release or .NET 5 only?

@pranavkm
Copy link
Contributor Author

pranavkm commented Nov 2, 2020

@augustoproiete we generally do not backport new features or non-critical bug fixes to earlier releases. You could consider using this PR as a template to copy to your application if you require this to work in your application.

On a side note, it's incredibly easy for us to miss comments on closed issues or PR. For the next time, please consider filing a new issue so there's clear visibility.

@dotnet dotnet locked as resolved and limited conversation to collaborators Nov 2, 2020
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-approved API was approved in API review, it can be implemented area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ASP.NET Core model binder deserilises UTC time string to local time rather than UTC time
6 participants