Fix DateTime deserialisation to respect timezones

[nickevansuk]

Without DateParseHandling = DateParseHandling.DateTimeOffset, the timezone gets truncated during deserialisation. Need to port some tests in to go along with this but thought I'd get this in while I was working on it.

Anyone very welcome to add a quick encode/decode test to show this working!

[RehanSaeed]

Do you have time to carry this forward or do you need help?

[nickevansuk]

Hey @RehanSaeed sorry for being slow to move this forward. I'm shortly going on leave until the new year so my attention has been focussed elsewhere.

Help very much appreciated :)

[RehanSaeed]

No problem, I'm in a similar situation. Will see if I can update your PR with these changes if I have time or maybe you will get there first.

[RehanSaeed]

@Turnerj Have you seen this PR. The MaxDepth is a nice security addition and I'm not sure about the date handling.

[Turnerj]

MaxDepth is interesting, hadn't thought about that yet. While we still use Newtonsoft.Json, it probably is a good idea to include a MaxDepth value as the default is no max depth. For System.Text.Json, the default is 64 MaxDepth.

Regarding the DateTimeOffset changes, that should be fixed from our changes to the ValuesJsonConverter for reading values as covered by these tests:

https://github.com/RehanSaeed/Schema.NET/blob/d9c7c7b6220655f0bd142f27b714d59a6cb4d432/Tests/Schema.NET.Test/ValuesJsonConverterTest.cs#L194-L216

[Turnerj]

We also now have a custom SchemaSerializer class that is our middle-man to whatever serializer technology is underneath, it wouldn't be a big change to add MaxDepth to our deserialization options.