You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this commit (6e4d096), 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.
The text was updated successfully, but these errors were encountered:
In this commit (6e4d096), 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.Utc
rather than plainDateTimeKind.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.The text was updated successfully, but these errors were encountered: