[datetime] Keep track of recording time trough the different processes

[Edouard2laire]

This makes sure all the common processes affect the date of acquisition well

• [x] process_timeoffset

For process time offset, two behaviors are possible. Either it modifies the time vector and the 'actual time of the event'. Let's say a spindle is detected at t = 60s and the acquisition date is 4 pm. If a timeoffset of 3600s is added to the file. The file now starts at t = 3600s, and the spindles is at t = 3660s, corresponding to 5 pm. The acquisition date stil indicate 4 pm.

If the checkbox is checked, the acquisition date is changed to 3 pm. The file still starts at 3600s, the spindles are still at t = 3660s, but it now corresponds to 4 pm. The timevector changed, but the actual time of the spindles didn't.

This can be usefull if you use the timeoffset in concordance with extract time: Let say you do extreaact time [ 3600, end] then want this new file to start at t=0s (for synchronization) then adding an offset of -3600s would create a wrong time information (as we dont really want to add an offset but just correct the time vector). Then in this case, we want to check the box and keep the same 'actual time' for the events.

I think it would have been cleaner to add an option in the extract time so the created file starts at t = 0s, but because the extract time is a filter, it's quite difficult to tinker with the events and acquisition date. I think this is a good compromise.

• [x] Synchronize recordings Done. I also added some information in the history about the offset between files.

• [x] Combine recordings

Note: For synchronizing and combining recordings, I had to use a user-interaction to find what is the correct date when multiple dates are present. This won't work if those two processes are called from a. script. Is there a better way to do it?