-
Notifications
You must be signed in to change notification settings - Fork 94
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
PrereleaseCompatibilityTransformer mishandles date/times in property bag #1577
Labels
Comments
This is not a bug in the |
This was referenced Sep 26, 2019
ghost
pushed a commit
that referenced
this issue
Sep 30, 2019
…#1688) I added a comprehensive end-to-end test of round-tripping property bag properties. I also added a `DateTime` test to the `PropertyBagConverterTests` functional tests. The problem that @ScottLouvau ran into with the `DateTime` test is related to my fix for #1577. I don't mean that my fix caused his problem; I mean that to avoid the problem, we need to do the same thing I did to fix #1577. For an explanation, see [this comment](https://github.com/microsoft/sarif-sdk/blob/83ecf0fa2d919a0be70a144464fc25d8b898a294/src/Sarif/SarifUtilities.cs#L190-L214) in SarifUtilities.cs. In short, when Newtonsoft.Json deserializes a string-valued property that looks to it like a `DateTime`, its default behavior is to convert it to a `DateTime` object. That behavior breaks our property round-tripping. To avoid it, we need to call `JsonConvert.DeserializeObject` with a `JsonSerializerSettings` object that specifies `DateParseHandling.None`. That tells Newtonsoft.Json to leave string-valued properties alone and let us handle the `DateTime`-iness. In #1577, I introduced `SarifUtilities.DeserializeObject` to do exactly that. @michaelcfanning and I have discussed this and we know it's not the end of the story. It's too easy to forget (or not to know about) the need to call the `SarifUtilities` method, which is exactly what happened in that existing unit test. But as far as verifying that our handling of property bag properties is good, I believe we now have sufficient test coverage to be confident of that. Also: - Fix a NuGet packaging warning. - Improve our internal handling of property bag properties with `null` values.
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given the input file:
repro-1577.sarif.txt
the command
produces the output file
repro-1577-transformed.sarif.txt
Note that
invocation.startTimeUtc
is correctly left alone, but a date/time value in the property bag is transformed from the quoted string"2019-06-22T19:06:31.209Z"
to the unquoted and reformatted string6/22/2019 7:06:31 PM
.The text was updated successfully, but these errors were encountered: