JsonServiceClient deserialization of datetime
Is it possible to affect how the JsonServiceClient deserializes DateTime properties of DTO’s.
It appears that even though UTC dates are returned on the wire from my service (JSConfig.AssumeUtc + JSConfig.AlwaysUseUtc) the client is deserializing them as DateTime.Kind = Local.
Doug Schmidt:
What version of SS.Text are you using? And can you post an example serialized DateTime that you think should be UTC?
My experience is that SS.Text is very strict on what it considers to be a UTC string. When it doesn’t know for sure, I have found it to still yield a local DT instead of UTC.
Jezz Santos:
Yes sure Doug,
On the server we are setting: JSConfig.DateHandler = DateHandler.ISO8601 so dates are coming back on the wire in this format: "YYYY-MM-DDTHH:MM:SS+12:00"
And after serialization by JsonServiceClient, I am seeing the DateTime property of the DTO in Kind=Local rather than Kind=UTC. Does that make sense?
I have looked about the web on this issue and see that some posts say the JsonServiceClient might use a specific deserailizer, so wondering if we can affect it ourselves? like we can the service (with JSConfig)?
Doug Schmidt:
I’m just on my phone right now, so I’m going from memory, but I think SS.Text really wants UTC strings to end in “Z”, not “+/-tzOffset”. I’m not 100% sure, but that’s my suspicion.
I believe you can override via JsConfig<DateTime>.DeSerializeFn. Also be aware that OrmLite.SqliteProvider can take a slightly divergent path with DateTime strings as well.
I’ll try to provide a better response tomorrow after I’ve had a chance to look at a real computer.
Who am I kidding? Demi’s will probably have this all figured out by the time I wake up.
JsConfig.AlwaysUseUtc on the client should deserialize it as UTC, here are a couple of tests to show this:
https://github.com/ServiceStack/ServiceStack.Text/blob/master/tests/ServiceStack.Text.Tests/JsonTests/JsonDateTimeTests.cs#L636-L662
Jezz Santos:
OK thanks. So presumably using JSConfig has the scope of the entire client process (i.e. Singleton), is that a correct assumption?
Given that. I know I can use the BeginScope method to scope the JSConfig settings which is very nice. Since we have our own wrapper for JsonServiceClient, it may make sense to use that scope around the lifetime of our wrapper class contain the impact on the whole process. Sound doable?
Yeah the config properties on JsConfig are static which you should initialize once on AppStart.
Yep, you may want to check out our approach for custom JSON Serialization used in the StripeGateway:
https://github.com/ServiceStack/Stripe/blob/master/src/Stripe/StripeGateway.cs#L392