Non-regular timestep, drift and timezone/correction light

[Rafnuss]

The logger itself does not know or record time zone. The user and Windows software is designed so that the user sets GMT+0 (UTC+0). However, this only works if the user has set their computer correctly or has input the time correctly (it can be input manually).

The logger uses the start time to timestamp the data. Drift adjusted files interpolate the calculated clock drift (calculated from user PC start time and user PC stop time) linearly across the data.

If you say your data file is UTC+2 then the user has set the start time wrong by 2hrs. We can see this when we look at the drift value in the header data. Drift should be less than about 5mins per year. The drift showing is -7094 seconds. 2x60x60 = 7200 seconds. So the stop time was correct but the start time was wrong. And the real drift time was +106seconds. The drift is +ve if the logger is slow.

So subtract 2hrs from all the timestamps and things should be correct or, more accurately, do this and then interpolate the 106seconds across the whole data record (the first timestamp being unchanged (so should be 30/05/2022 15:26:15), and the last timestamp having the full 106secs correction (add 106secs) IF the logger stopped BEFORE that sensor data memory was full (next to the drift time in the header it says 'not full' so this is indeed the case with this deployment record and the 106secs of clock drift calculated was indeed the drift at the time of the last timestamp).

(Note, if you are doing this with other files, if their memory is filled, then the clock drift should be interpolated across the whole of the period between the start and stop times. The last datum timestamp will be earlier than the stop time because the memory filled, and so will not correspond to the full drift value.)

[Rafnuss]

Also, currently exportthe firt twilight as the first time of recording of light (first datapoint) (oulier in trainset). This should be fixed