OASIS Static Analysis Results Interchange Format (SARIF) TC

 View Only

RE: Change draft for #287: default for lastDetectionTimeUtc

  • 1.  RE: Change draft for #287: default for lastDetectionTimeUtc

    Posted 12-10-2018 21:50
    I wrote a new change draft with the modified design:   Documents/ChangeDrafts/Active/sarif-v2.0-issue-287-lastDetectionTimeUtc-default-min-invocation-start-time.docx   … and moved the change draft with the original design to the Rejected folder:   Documents/ChangeDrafts/Rejected/sarif-v2.0-issue-287-lastDetectionTimeUtc-default-with-run-startTimeUtc.docx   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Monday, December 10, 2018 1:18 PM To: Michael Fanning <Michael.Fanning@microsoft.com>; OASIS SARIF TC Discussion List <sarif@lists.oasis-open.org> Subject: [sarif] RE: Change draft for #287: default for lastDetectionTimeUtc   @michaelcfanning  and I discussed this offline. I reminded him that the earliest  invocation.startTimeUtc does not necessarily equal the run's start time (for reasons I explained in an  earlier comment ). He replied by reminding me of the driving scenario, which is: ... to identify the time of detection for a result. It is helpful for this value to be consistent, i.e., there should be a single timestamp for an analysis run. From this angle: find the earliest timestamp from the array of invocations seems fine as a simple, reliable way to get what’s required.  I understand conceptually that doing this might not precisely describe the actual start of a run, but do we care? The real point here is: ‘this results has been raised since build XXX on date YYY’. We’re providing a slot for a date as a convenience, so that users aren’t required to go look up information associated with the instance id. (Emphasis added) I find that convincing, and I'm going to revise the change draft accordingly. We don't need to restore  run.startTimeUtc  (or  run.endTimeUtc , which I had restored just for symmetry). Larry   From: Michael Fanning < Michael.Fanning@microsoft.com > Sent: Monday, December 10, 2018 9:30 AM To: Larry Golding (Myriad Consulting Inc) < v-lgold@microsoft.com >; OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org > Subject: RE: Change draft for #287: default for lastDetectionTimeUtc   Hi, Larry,   I am not sure resurrecting run.startTimeUtc makes sense, please see my most recent reply.   I led us to this situation because I forgot that we removed this property. All things considered, introducing it again seems like it brings more complexity without much incremental value.   Michael   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Sunday, December 9, 2018 1:56 PM To: OASIS SARIF TC Discussion List < sarif@lists.oasis-open.org > Subject: [sarif] Change draft for #287: default for lastDetectionTimeUtc   I pushed a change draft for Issue #287 : “Define default for resultProvenance.lastDetectionTimeUtc”.   Documents/ChangeDrafts/Active/sarif-v2.0-issue-287-lastDetectionTimeUtc-default.docx   In the issue’s discussion thread, Michael and I decided that it made sense to bring back the property run.startTimeUtc . Please read the thread to see how that idea is related to this issue. So we’ve restored that property, and for symmetry, also restored run.endTimeUtc .   We’ll move its adoption at TC #29 on Wednesday December 12 th .   Thanks, Larry