ASP.Net API DateTime ISO8601 date value being parsed as default date (01/01/0001 00:00:00) in production & Azure

I’m seeing an issue when our API is parsing the post values. This only appears to be happening in the live environment, hence it was missed during testing.

This class represents what is posted to the API:

public class LoginHistorySearch
{
    public DateTime StartDateUtc { get; set; }
    public DateTime EndDateUtc { get; set; }
}

Cutting right down to the core issue, here is the parsed date returned back as a response:

[Authorize]
[Route("Reports/LoginsByPeriod")]
public class LoginsController : ApiController
{

    public HttpResponseMessage Post([FromBody] LoginHistorySearch search) {
        return Request.CreateErrorResponse(HttpStatusCode.OK, search.StartDateUtc.ToString());
    }
}

If I post this data (currently using APITester.com):

{
"StartDateUtc": "2018-01-01T00:00:00Z",
"EndDateUtc": "2020-01-01T00:00:00Z"
}

I get this returned:

Response Body
{"Message":"01/01/0001 00:00:00"}

Even more strangely if I post using Postman, then I see an IIS 404 error.
Can anyone please explain this?

Contents hide

Updates

Answers:

Method 1

Updates

Published to an Azure App Service – seeing the same outcome
Windows Server uses en-GB locale (United Kingdom)
Added DateTime.Kind to setter in class to enforce UTC

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

After double checking every setting, it emerged that the Content-Type header was being dropped on creating the POST for the live site.

Adding this in manually produced the desired output and triggered the correct parsing:

Content-Type : application/json

(Blood pressure resuming normal rate)

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes

Article Rating