-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parsing 0.0 (decimal) different in 13.0.2 #2768
Comments
Nice catch. The behavior seemed to have changed with 13.0.2. The cause of the issue is in commit 13717cf#diff-188cdcd35a8220c2477c864944a945fa67539c0beac51d3909424ff07dea7fe4 based on this pull request #2639 Specifically, the Newtonsoft.Json/Src/Newtonsoft.Json/Utilities/BoxedPrimitives.cs Lines 90 to 92 in 4fba53a
For any numerically zero value with trailing zeroes like 0.0, this method unfortunately returns |
Should fix this. Is there a way to detect whether a decimal has trailing zeroes without ToString? If there is then decimals with trailing zeroes can skip the cache. If there isn't then remove caching of decimals altogether. |
I know of two ways. However, both are available only beginning with .NET 7. The following expressions yield false for a zero value with trailing decimal zeros, and true for a zero value without trailing decimal zeros (not sure which of these two would perform better, though): Using decimal.IsCanonical(decimal): or using decimal.Scale: Dotnetfiddle showing both decimal.IsCanonical and decimal.Scale in action: https://dotnetfiddle.net/qa2XD1 |
I think decimal.GetBits, then checking the flags value in the span, should work in .NET 6 - https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Decimal.cs,602 |
PR: #2769 |
Is this related / will the PR address negative zero (-0.0) is now being (de)serialized as 0 instead of -0? |
It's related but existing PR doesn't fix it. New PR for negative doubles: #2777 |
After using Newtonsoft.Json version 13.0.2, I encountered an unwanted behavior.
Source/destination types
Expected behavior
I would expect that the decimal
0.0
contains still the trailing zero after parsing.Actual behavior
Decimal looses precision after parsing. The trailing zero (
0.0
) is gone.Steps to reproduce
See above unit test.
The text was updated successfully, but these errors were encountered: