In this commit (https://github.com/intuit/QuickBooks-V3-DotNET-SDK/commit/6e4d096828c584b5a3be6fccaf7126dde1b47d1b), the deserializer was changed to use the same settings as the serializer. This change had the effect of changing the date deserialization handling from DateTimeZoneHandling = DateTimeZoneHandling.RoundtripKind (the default, since it was previously unspecified) to DateTimeZoneHandling = DateTimeZoneHandling.Utc.
This broke our application after upgrading to this version. Plain dates that come back from QBO like Invoice.TxnDate are now getting interpreted as DateTimeKind.Utc rather than plain DateTimeKind.Unspecified as was previously the case. This results in a date like "2024-04-18" in the response JSON getting transformed into the equivalent of "2024-04-17T16:00:00-08:00" due to the incorrect interpretation of "2024-04-18" as a UTC date/time rather than a zoneless date/time.
In this commit (https://github.com/intuit/QuickBooks-V3-DotNET-SDK/commit/6e4d096828c584b5a3be6fccaf7126dde1b47d1b), the deserializer was changed to use the same settings as the serializer. This change had the effect of changing the date deserialization handling from
DateTimeZoneHandling = DateTimeZoneHandling.RoundtripKind(the default, since it was previously unspecified) toDateTimeZoneHandling = DateTimeZoneHandling.Utc.This broke our application after upgrading to this version. Plain dates that come back from QBO like Invoice.TxnDate are now getting interpreted as
DateTimeKind.Utcrather than plainDateTimeKind.Unspecifiedas was previously the case. This results in a date like "2024-04-18" in the response JSON getting transformed into the equivalent of "2024-04-17T16:00:00-08:00" due to the incorrect interpretation of "2024-04-18" as a UTC date/time rather than a zoneless date/time.