Re: Adding userTag to epicsTimeStamp

[Ralph Lange <ralph.lange@gmx.de>]

I don't know.

I would expect the user tag to come from a different source than the wall clock time, and be assembled into the NT timeStamp structure.

In the NT discussion we expected 32 bits to be good enough for a user tag. More than four billion different values for a tag seem plenty.

In general, the NT types were discussed, reviewed and set over years. I would not expect to see them changed on an ad-hoc basis.

Not saying that this specific tag should not be 64 bits wide, but to change an existing approved design, I would like to see a minimum amount of justification and discussion.

Cheers,
~Ralph

On Mon, Oct 9, 2017 at 2:23 PM, Johnson, Andrew N. <anj@aps.anl.gov> wrote:

I just tried modifying the definition of the epicsTimeStamp object, adding an epicsUInt64 userTag member to it. Everything built without problems and the tests all passed. Then I looked through pvDataCPP and connected this to the userTag in property/timeStamp.cpp.

Any lab that wants to use this would have to set the userTag in their generalTime time provider(s).

Observations:

1. I have not added userTag to the epicsTime class, which is different to an epicsTimeStamp. C++ code tends to pass around epicsTime objects by value, and I’m reluctant to double the size of that object unnecessarily.

2. Some work would be needed to support the userTag in epicsTimeToStrftime(). There are some free conversion format characters left: %i %J %K %L %N %o %q %Q (comparing MacOS and Linux docs plus a few others inline).

3. There are few tests for userTag in pvData/testApp, not sure if any could really check what I did.

4. I used an epicsUInt64 because someone (maybe Dirk Zimoch?) asked for it to be 64 rather than 32 bits. The PVA timeStamp userTag was defined to be 32 bits, should we consider changing it to 64?


Is doing this a good idea, and if so is it the right approach?

- Andrew