Within the original extended time code, it was possible for the following situation to occur:
Here is an example from PublishedMetadata database entries:
|2722||624||extendedTime3||2c7f87e6-360a-4383-8dea-b452013bbc69|1560|05/17/2016 11:35 am|05/17/2018 11:35 am|05/17/2018 11:35 am|
AssessmentID and Label should be a unique pair.
This occurred on 11.x based on 7eb73319d75. It also occurred locally on our original extendedTime code.
This is not a good situation. Extended time data is retrieved using the getAssessmentMetaDataByLabel method. As there are two labels for the same AssessmentID it's a toss up on which entry would be retrieved. This can result in odd behavior (entries showing up in the UI, refreshing, and then not being present); this behavior is what was experienced in the original 2.9 implementation.
To resolve this, I've refactored how extendedTime entries are saved.