DateTimeOffset modelbinding from form is always set to utc in net7

[yannicsmeets]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Hello,

I have the following model that is used as input of a controller method:

public class TestController : ControllerBase
{
    [HttpPost]
    public DateTimeOffset Post([FromForm] InputModel model)
    {
        return model.StartDate;
    }
}

public class InputModel
{
    public DateTimeOffset StartDate { get; set; }
}

When I sent the string '2022-11-29 10:00' in NET6, the local timezone offset (+1 in my case) is used for the DateTimeOffset. However, in NET7, the offset is always 0.

Expected Behavior

I expect the datetimeoffset is parsed with the local timezone offset, if none is provided in the input string.

Steps To Reproduce

https://github.com/yannicsmeets/datetimeoffset-demo

The main branch is net6. In the net7 branch, the target framework is set to net7.0

Exceptions (if any)

No response

.NET Version

7.0.100

Anything else?

No response

[captainsafia]

Triage: @brunolins16 has a hypothesis that adding support for TryParse in MVC's modelbinding might be following into a pathway that is different from the pre-existing binding in the rules it uses. He'll take a look further.

[brunolins16]

I did some investigation and I believe the introduction of the TryParseModelBinder, evaluated earlier than the SimpleTypeModelBinder, caused the issue.

When binding using the TryParseModelBinder the DateTimeStyles is set to DateTimeStyles.AssumeUniversal | DateTimeStyles.AllowWhiteSpaces while the binding using the SimpleTypeModelBinder, call to DateTimeOffsetConverter, will set it to DateTimeStyles.None causing the behavior mentioned above.

[captainsafia]

Triage: Action here to document the breaking change.

Evaluate if we can invoke the SimpleTypeModelBinder before the TryParseModelBinder to maintain the pre-existing behavior and service this breaking change.

@brunolins16 Will look into if we are using AssumeUniversal consistently across DateTime and DateTimeOffset.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.