CreatedAtRoute with DateTimeOffset gives incorrect URL

[MikaelUmaN]

Describe the bug

DateTimeOffset string is formatted incorrectly in location link after returning CreatedAtRoute result.

To Reproduce

Steps to reproduce the behavior:

• Given HttpPost route
• Given a CreatedAtRoute result including a DateTimeOffset parameter
• Then the location parameter should include a valid string representation of the DateTimeOffset value.
• Instead, an erroneous value is given:

 content-length: 0 
 date: Wed, 12 Jun 2019 07:58:27 GMT 
 location: http://localhost:8081/api/monitor/IntradayOutlierMonitor/IntradayOutlierMonitor/06%2F13%2F2019%2007%3A26%3A21%20%2B00%3A00 
 server: Kestrel 

Expected behavior

String formatted in a manner that makes it parseable by AspNetCore if the target route is called.

Can be achieved manually by doing this:

return CreatedAtRoute(nameof(GetConfig), new { name = config.MonitorName, validFrom = config.ValidFrom.ToString() }, null);

that is, calling ToString() explicitly. Then the location parameter becomes:

http://localhost:8081/api/monitor/IntradayOutlierMonitor/IntradayOutlierMonitor/2019-06-13%2007%3A27%3A21%20%2B00%3A00
which is accetable to AspNetCore

Screenshots

I get errors uploading screenshots, but trying to use the uri results in the following json

{
errors: {
validFrom: [
"The value '06%2F13%2F2019 07:26:21 +00:00' is not valid."
]
},
title: "One or more validation errors occurred.",
status: 400,
traceId: "0HLNF1F0EM637:00000002"
}

[mkArtakMSFT]

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimalistic repro project that illustrates the problem.

[MikaelUmaN]

Please see repo:
https://github.com/MikaelUmaN/AspNetCore-11134

Reproduce

CLI (sdk >= 2.2)

dotnet build
dotnet run

HTTP Client (e.g. cURL)

1. POST http://localhost:5000/api/values

Response:
location:
http://localhost:5000/api/Values/06%2F13%2F2019%2008%3A43%3A24%20%2B00%3A00

2. Put in browser

-> Error

[pranavkm]

Thanks for the repro app @MikaelUmaN.

Unfortunately you're running in to a fairly problematic issue on the incoming end that we decided not to fix in the past: aspnet/Mvc#4599, aspnet/Mvc#6388. We do have an issue to do a fairly targeted fix during input: #11544. We'll use the other issue to track fixing this scenario.