Comment 3 for bug 1722530

The epicsTimeStamp::secPastEpoch field is already unsigned so not subject to the 2038 overflow problem, and when it does hit its limit sometime after 2100 nobody should still be using CA (if they're still using EPICS). Since we don't *need* to change this (and we already have our own epoch so timestamp conversions are already required) I don't see a particular advantage to making that 64-bit.

I did just notice though that db_access.h uses epicsTimeStamp in all the dbr_time_* types, so my experiment would have broken CA if I'd tested with an external CA client. Additional work would thus be required to remain compatible with older CA versions, and it would probably be safer to change the name of the IOC's data type. I just lost my desire to do this.