[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Change draft for #287: default for lastDetectionTimeUtc
I wrote a new change draft with the modified design:
… and moved the change draft with the original design to the Rejected folder:
I discussed this offline. I reminded him that the earliest
... 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.
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.
I pushed a change draft for Issue #287: “Define default for resultProvenance.lastDetectionTimeUtc”.
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 12th.