Based on the response on this question here: What are The Unit of measurement and extrapolating, it seems that when reading the timestamps from the imu datasource (imu9), th
UPDATE:
A way to get UTC vs RelativeTime difference has been added in 1.7. Please see the GET /Time/Detailed -API.
The Movesense sensor has one clock source (32kHz 20ppm crystal stabilized low-frequency tick counter) which runs at 1024 ticks/second. From there the "RelativeTime" [ms] is calculated (ms since reset). RelativeTime is returned as timestamp from many sensor measurements and is based on the xtal stabilized clock, so it is stable. Since especially the IMU unit (Acc/Gyro/Magn) sampling is timed by the LSM6DSL's internal RC oscillator, the diff of timestamps can vary and the real samplerate is +-10% of the nominal given in the subscription parameter. The ECG samples are accurate since that chip uses the clock signal from the stable oscillator.
The UTC clock is calculated with an offset to the RelativeTime. So internally the UTC clock is calculated in ms, while the API has microseconds in case there are future hardware with better capabilities.
When PUT /Time is performed, the sensor uses the given UTC time to calculate a new offset between the UTC clock and RelativeTime and takes it into use. The PUT request over BLE takes some time that can be estimated by PUT-GET round trip. If a more accurate setting is wanted one can use the CustomGATTService module (/Comm/Ble/GattSvc) to implement simpler time setting service that avoids all the MDS/Whiteboard protocol overhead. Typically BLE connection interval seems to be around 45ms-60ms, so that much delay is expected anyways.
The current published Movesense device lib does not offer a convenient way to find out the relation between UTC time and RelativeTime on the sensor. However the coming 1.7 release (due in few weeks) will have it and simplify multi-sensor synchronization.
Full disclosure: I work for the Movesense team