using TAI #66
Description
This just bit us:
Line 13 in 096f2bb
We've been missing that it switched to TAI since 9e3400b. We have a bunch of things using milk but not using all of its API that are setting CLOCK_REALTIME.
An issue is that not all O/S just handle TAI. MagAO-X is on Rocky 9, and the TAI offset is not set up without intervention (so we don't think we actually have a problem in past data). But running this on the SCOOB bench with ubuntu we found various streams off by 37 seconds. Nobody did anything to set up TAI there.
We use timestamps generated by hardware for atime, e.g. the EDT PCIe card generates a timestamp (https://edt.com/api-pdv/group__acquisition.html#gac1baf026dc40577145a629b8c81f4ec0) which uses gettimeofday, which is system clock time. Similar feature in Princeton/Teledyne stuff. So unless you have actually changed your system clock to TAI, you now have a 37 sec offset between atime and writetime.
In applications where we're streaming from one computer to another, this causes problems (e.g. a remote control computer might be a personal laptop on a different O/S, and it will now think it's 37 seconds off).
We need to know this and understand it if we're using the shmim timestamps for astronomy, e.g. FITS recommends that DATE-OBS be in UT. All manageable of course, but many pipelines are going to expect that. So anything that has the job of creating a data product from shmim timestamps needs to know about this.
I can go on. Long term I think TAI is the right choice (and maybe required by Subaru?). But this is a mess. As time always is.
Can/should this be a cmake option?
What if we added flags to IMAGESTRUCT, i.e. specifying clock and timezone for atime and writetime?