DateTime in DTO is null after Servicestack update

My DTO has a property

public DateTime? Date {get; set;}

This DTO was correctly deserialized when I was on version 4.0.34. However, recently I updated the entire system to 4.0.40 and I’ve noticed that the Date property ends up being ‘null’ in my POST request.

Any idea why this might be the case? Is there a possible issue with deserialization when the name of the property is Date?

I can’t tell what the issue is, can you submit a stand-alone repro/failing test to:

The problem appears to be in the date format. It doesn’t like 06/28/2015 anymore. This used to work, but after the update it stopped. If I change the date to 6/28/2015, it works fine. Thanks!

Here’s a gist to repro the issue:

Fail: http://localhost:8088/test.json?Date=06/28/2015

Pass: http://localhost:8088/test.json?Date=6/28/2015

Please see the correct way to unambiguously specify dates:
To minimize issues you should always use the above format when specifying dates across the wire.

You can workaround this issue atm by adding a parse error fallback:

DateTimeSerializer.OnParseErrorFn = (s, ex) => {
    var parts = s.Split('/');
    return new DateTime(int.Parse(parts[2]), int.Parse(parts[0]), int.Parse(parts[1]));

The reason why it works for D/MM/YYYY is because it avoids manual date parsing and falls back to DateTime.Parse(). I’ve also added a fix where it will fallback to DateTime.Parse() if an invalid dateformat was provided, so it should now support all different formats in this commit. Although the recommendation is still to use the unambiguous YYYY-MM-DD where possible.

This change is available from v4.0.41+ that’s now available on MyGet.

Thanks for the pointers. While prototyping, I had simply passed the value to the backend that bootstrap datepicker had provided. It makes sense to change to the YYYY-MM-DD format.

I love the fact that you have a pre-release nuget!! And, thanks for a quick fix as well as the workaround for catching parsing errors!