openrowingmonitor
openrowingmonitor copied to clipboard
Recording's file names have UTC date/time, not local
On a raspberry pi 3b+ with
$ uname -a
Linux rower 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
$ sudo ./updateopenrowingmonitor.sh
Update script for Open Rowing Monitor
Checking for new version...
You are using the latest version of Open Rowing Monitor from branch "v1beta".
The filenames created for the *_rowingData.csv, *_raw.csv and *_rowing.tcx files have the UTC date/time in them rather than the local time.
After 10 strokes:
$ ls -l /opt/openrowingmonitor/data/recordings/2023/05/
total 12
-rw-r--r-- 1 root root 3846 May 17 12:46 2023-05-17_02-46-21_rowingData.csv
-rw-r--r-- 1 root root 5555 May 17 12:46 2023-05-17_02-46-21_rowing.tcx
$ date
Wed 17 May 2023 12:47:00 AEST
I'm in Australia/Sydney time zone which is 10 hours ahead of UTC.
$ cat /etc/timezone
Australia/Sydney
Assumption mode ON: I assume ORM isn't picking up the timezone, but I don't know how to fix this. The system timezone is correct.
We'll add this to the changes coming with a new version that is in the works. It will take some time before they reach the V1Beta branch though, it is quite a change (code refactoring sounds cool in theory, but is pretty tough in practice).
This is a kludged workaround. But since the stringifiedStartTime already has the timezone information stripped off, it has the end result of saving files with the expected time in the filename.
P.S. I couldn't upload the patch as a .diff or .patch, so it's WorkoutRecorder.diff.txt
This is a kludged workaround. But since the stringifiedStartTime already has the timezone information stripped off, it has the end result of saving files with the expected time in the filename.
P.S. I couldn't upload the patch as a .diff or .patch, so it's WorkoutRecorder.diff.txt
Thanks. As said, we are doing major architecture changes at the moment where we will include a patch very similar to this. But as the recorders are an integral part of this change, we can't include it in the current V1Beta_updates as we don't want to risk frustrating integration of the new architecture later on. But it is on our radar.