Thanks for you reply Butch, but my issue is not related to the precision of the values, it's the precision of the value time stamp. I couldn't find any references to this in the linked article.
3 of 3 people found this helpful
TL;DR the answer is 1/65536th of a second.
The precision of the AFTime written back to a PIPoint in the DataArchive is 1/65536th of a second. That's more of the PI DataArchive (aka PIServer) imposing that restriction.
In .NET code itself, the AFTime has a much finer precision. So AFTime.Now could return a time that would have to be slightly altered to align evenly on a 1/65536th of a second boundary when writing that time to the DataArchive. You will see this somewhere in the 6th or 7th decimal place of the UtcSeconds.
Using your example, which already nicely shows only the seconds portion from UtcSeconds, and what I call a PIsubsecond of (1/65536), then
48.3397361 / (1/65536) = 3187653.745 PIsubseconds
However, we cannot have "non-whole" PIsubseconds. Thus that value's ceiling is taken to produce 3187654 PIsubseconds so that it evenly aligns on that 65536 boundary. We can then calculate the time that will be saved:
3187654 / 65536 = 48.63973999 seconds
Which is then saved back to PI.
1 of 1 people found this helpful
AFTime.ToPIPrecision Method can be used on the client to pre-round your AF time stamps into PI Data Archive precision.