Since 1.22.1, the ability to customize the parsing of DateTimeOffset by adding a JsonConverter<DateTimeOffset> to the context has been lost. The use case I had for doing this was to customize the handling of values without a timezone to default to UTC rather than local timezone.
The problem appears to have been introduced in #670 - the previous handling would try to deserialize via TryGetUsingTypeInfo, then fall back to DateTimeOffset.Parse. The new handling first tries JsonElement.TryGetDateTimeOffset (which does not use the converters in the options) then falls back to TryGetUsingTypeInfo. Since a value without a timezone specifier does get handled by JsonElement.TryGetDateTimeOffset, the JsonConverter<DateTimeOffset> never gets invoked, and I end up with values in the wrong timezone.
Please either restore the previous behaviour where the conversion that takes account of JsonConverter<DateTimeOffset> is tried first, or provide another way to customize the parsing.
Since 1.22.1, the ability to customize the parsing of
DateTimeOffsetby adding aJsonConverter<DateTimeOffset>to the context has been lost. The use case I had for doing this was to customize the handling of values without a timezone to default to UTC rather than local timezone.The problem appears to have been introduced in #670 - the previous handling would try to deserialize via
TryGetUsingTypeInfo, then fall back toDateTimeOffset.Parse. The new handling first triesJsonElement.TryGetDateTimeOffset(which does not use the converters in the options) then falls back toTryGetUsingTypeInfo. Since a value without a timezone specifier does get handled byJsonElement.TryGetDateTimeOffset, theJsonConverter<DateTimeOffset>never gets invoked, and I end up with values in the wrong timezone.Please either restore the previous behaviour where the conversion that takes account of
JsonConverter<DateTimeOffset>is tried first, or provide another way to customize the parsing.