From Section 5.4.3
"If a requested timestamp (server, source or both) is not supported for a HistoricalDataNode, the operation shall return the Bad_TimestampNotSupported StatusCode. For MonitoredItem the Server shall not return past data if a requested timestamp is not supported by the history collection."

I take this to mean that you can ask for a timestamp from the server timestamp and if it is supported by the server then the server timestamp will be the one used in the aggregate calculations etc.

I cannot figure out how it makes any sense to return server timestamps for aggregate data. The data is collected and aggregated based on the source timestamp. For most of the aggregates, the timestamp is specified as the beginning of the interval which is based on the source timestamp. What could "server timestamp" possibly mean in this context?

I think we need to have a phone discussion on this.

I re-read part 4.3 in part 11. I was misreading it when it says the request is always in source timestamps but the reply could be in any of the timestamps available. So the issue is for requests only. So yes, I agree then that there is no case for the request to come in as server timestamp because that isn’t allowed.

In this case I propose that the request is rejected with Bad_TimestampsToReturnInvalid.

Agreed to proposed solution in telecon.

Section 5.4.3 was changed to include "If a requested timestamp is set to anyhting but the source timestamp the operation shall return the Bad_TimestampToReturnInvalid StatusCode."

Making edits.

fixed in 1.02.11

Agreed to close in telecon (without review).