Hmm, good point, but i think that for any output timestamp you would be able to determine if it's future or historical:
- Trigger time: always current time, this historical
- Fixed timestamps: one could safely assume that if the data is in the future now, you need a future point, else historical.
- Relative timestamps: if positive offset: future, if negative offset: historical.
So although there might be ambiguity on the timestamp, it can be evaluated on definition (or instantiation) of the analysis i think.
This seems clear to me:
A flag that determines the type of PI point to create for newly mapped output attributes that save output history when the time stamp of the output is uncertain. PI Analysis Service attempts to create the PI point type that matches the time stamp of the output, future PI points for output with future time stamps or historical PI points for output with present or past time stamps. If set to False, PI Analysis Service creates historical PI points in cases when the time stamp of the output is ambiguous. If set to True, PI Analysis Service creates future PI points in cases when the time stamp of the output is ambiguous
you may replace ambiguous by "in future".
With PI 2015, there are now two types of archives, future and historical. And to store data into a future archive you need a different tag type. So to me the future is ambiguous somewhere between * and *+10m. ( Recall that historical tags can support to write in the future, but only 10m ahead?). So to me this is where the ambiguity is.
Please see Mike's and David's answers, they have answered the question in a very detailed fashion.
The CreateFuturePIPointsForAmbiguousOutputTimes option:
- When true: if value is between * and *+10m a future tag will be created..
- When false, if value is between * and *+10m an Historical tag will be created..
ps: I have not tested it.
hope this make sense
Ah yes! The future that is now, which we always had on the pre-2015 Data Archive: the 10 minutes of future...
4 of 4 people found this helpful
Neither of the other answers are correct. Ambiguous timestamp has a specific meaning relating to the analysis' Output Time Stamp override (AFAnalysis.OutputTime). An ambiguous setting is one where it cannot be determined if the data will be written to the future based solely on the setting. For example, "t" is clearly in the past so a historical point is created, if needed. And "*+10m" is clearly in the future so outputs will be created that are "future" points. However something like "t+10h" or "Tue" depends on when the analysis is scheduled to run. In the former case, if the analysis only ever run at noon (which could happen because that's when the triggering data comes in or because it is scheduled to run periodically then), then a historical tag could be used. However if data comes in every hour then a future tag would be needed to successfully write every value. The CreateFuturePiPointsForAmbiguousTimeStamps affects this automatic creation of output for these scenarios. When there is an ambiguous value, a setting of True causes output tags created to be future tags and False causes them to be plain old historical tags.
For the record, we classify as "ambiguous" any valid time string (as parsed by AFTime) for Output Time Stamp that does not match one of the following categories:
Trigger time - '*' or empty string
Execution time - 'ExecutionTime'
Fixed positive offset - Examples are '*+1h', '+1m', '*+1m', '*5'.
Fixed negative offset - Examples are '*-1h', '-1m', '*-1m'.
Variable past offset - Examples are 't-1h', 't', 'y'.
The "Fixed positive offset" category is classified as always using a future tag for outputs.
2 of 2 people found this helpful
And just to add to that. If Output Time Stamp override is determined to be clearly in the future (Fixed positive offset) even less than 10 minutes.. such as "*+1m", the PI point is created as the "future" PI point - the CreateFuturePIPointsForAmbiguousOutputTimes does not have effect in those definite cases (no 10 minute magic consideration).
Thanks David, this is a very good remark.
I have marked your answer as correct as this is better detailed and less confusing.
Thanks for your help!
Thanks Mike, all previous answers made sense, until your's showed us the correct explanation. Did not think about the truly ambiguous examples you mention.