Comment 9 for bug 1722530

Ralph: I agree, but with pvAccess providing a user-tag I'm happy to at least consider what would have to be done to support it properly in the IOC database. I assume Michael is being asked to do something like that by SLAC. Other sites with pulsed machines may want to attach tags to their timestamps but just haven't asked, so we don't really know where this might be used if it was available.

Separating the IOC's internal time-stamp data type from that used by CA's api and network protocol seems like a good thing to investigate for future flexibility anyway.

Michael: I guessed you were probably only thinking about DB links, but I don't want to side-step the new link-support APIs. That means only using the dbGetTimestamp(plink, pstamp) API to fetch time-stamp data from plink and write it to pstamp (there may be several links in the chain, and while there's no "db" JSON link type yet I don't want to preclude it in the future).

The epicsTime class needs to provide conversions to/from both definitions, so we can't have two different structure definitions for the same name. Thus I believe the One Definition Rule matters because of these conversion methods in libCom:

tux% nm -C lib/linux-x86_64/libCom.so.3.17.0 | grep epicsTimeStamp
00000000000342b0 T epicsTime::epicsTime(epicsTimeStamp const&)
00000000000342b0 T epicsTime::epicsTime(epicsTimeStamp const&)
0000000000034f60 T epicsTime::operator epicsTimeStamp() const

Those appear to be the only places where epicsTimeStamp appears in any C++ symbol though.