Comment 1 for bug 1182091

After discussion with Till Straumann and Freddie Akeroyd, we found the following usecases for this feature:

  - It's not intuitive that one can get the timestamp (e.g. using caget -a) by getting any field /except/ TIME.
  - Getting a 64-bit integer would simplify calculations.
  - Getting a double would also simplify calculations, albeit with reduced precision, and is better supported in EPICS. This would make it trivial to e.g. calculate time deltas using the calc record.
  - Getting two 32-bit integers is better supported than a 64-bit integer, but is a pain to use. Sometimes, one is only interested in seconds or only nanoseconds, in which case, CA filters could be used to get the desired value.
  - Writing to the timestamp: I'm sure there's someone out there who would like to have that, but it's not clear that it's a good idea and how it would interact with TSE and such.

We cannot change the underlying type of the TIME field as that would break the world. I have looked at two approaches: adding additional fields to dbCommon, and CA filters.

Adding an additional field could be done as follows:
  - Add a UINT64 field named TM64 (or something to that effect).
  - This field would contain a copy of the timestamp converted from the TIME field.
  - Handle the TIME field like fields with SPC_DBADDR are handled, except instead of calling cvt_dbaddr(), point to the data in TM64. This allows accesing the 64-bit timestamp through the TIME field.
  - Advantages:
    - Both TIME and TM64 are directly readable.
    - UINT64 will gracefully degrade to double and string: calc will work and caget will have full precision in ascii representation.
    - Additional fields can be added to serve seconds and nanoseconds separately.
  - Drawbacks:
    - No human-readable string (but I don't think that's a problem)
    - It introduces additional overhead for every single record. This is even more pronounced if more fields are added to provide seconds and nanoseconds separately.
    - I see no way to keep the timestamps in sync. One would need to wrap the rset::process() function, but that cannot be done because users outside of EPICS base may call it directly.

To implement this via CA filters, I propose extending the "ts" filter. It already has the right name, even though, given how general the name is, its current behaviour is oddly specific. It currently takes no arguments, so extending it shouldn't be a problem.

Advantages:
  - Seems easy to implement with no interference to other parts of the code.
  - Very flexible.
  - No overhead when not in use.
Drawbacks:
  - The TIME field itself would remain inaccessible. It was argued that one /can/ currently get the timestamp, but not in a straightforward way, and seems to me that CA filters are not yet part of users' muscle memory.