Clarified that the Bad_TimestampsToReturnInvalid can be returned as a service level result if the historian does not support ServerTimestamps or it can be reported as a operation level result if a given HistoricalDataNode does not support ServerTimestamps.

Agreed to changes edited in Virtual F2F.

The resolution of this issue was overwritten by the resolution for issue 0008534

The use of BadTimestampsToReturnInvalid makes only sense for service level and for the case where the TimestampsToReturn parameter is Neither.
I like the resolution of 0008534 much more since it uses a deticated status (Bad TimestampNotSupported) for the "server timestamp is not supported"

You need to remove the resolution text for this issue from part 11 and merge it with 0008534.

they are different issue and the second did not overwrite the first. One is for a selection of "Neither" which is never ok (and does not make sense). The other is for selection of Server (or Source & Server), which might be ok on a node by node basis or possibly never ok on a given server. Note: data is always retrieved using SourceTimestamps, even if only server is requested.

I fully agree with your lasts note.

But it is not what is written before as resolution.

Bad_TimestampsToReturnInvalid was always defined (at least in 1.04) as status for invalid TimestampToReturn values including NEITEHER.

But Bad_TimestampsToReturnInvalid was also listed as status for not supported Server timestamp. And this now ALWAYS Bad TimestampNotSupported which is different than descried for the resolution of this issue.

Updated resolution to have the correct statement:
if "neither" is specified in TimeStampsToReturn - return Bad_TimestampsToReturnInvalid
if a server timestamp is specified and the server does not support it for the node ,return code is Bad_TimestampNotSupported, could be for service or operation

Agreed to updated resolution note.