Minor correction of timestamp handling code in readGENEActiv

[l-k-]

I was looking at timestamp handling in GGIR, so looked at GGIRread as well, and saw this minor issue. It doesn't really affect anything besides understandability of the code, but I thought I'd send a small PR anyway.

Basically I removed an unnecessary operation.

starttime_posix object later gets converted with as.numeric(), which produces a Unix timestamp, which is always in UTC. So converting starttime_posix from configtz timezone to desiredtz doesn't achieve anything. The only thing that matters is that we use the correct timezone when converting from the original string representation to the POSIX object.

This extra operation wasn't breaking anything, but I think it's better to remove it so that there isn't any illusion from reading the code that the returned timestamps are somehow in desiredtz. They are unix timestamps, in UTC.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ca5a879) 90.03% compared to head (5a791ea) 90.01%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
- Coverage   90.03%   90.01%   -0.03%     
==========================================
  Files           9        9              
  Lines         903      901       -2     
==========================================
- Hits          813      811       -2     
  Misses         90       90              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[l-k-]

@vincentvanhees I was also wondering if you remember what + 5 is for on this line? I was curious and I couldn't figure it out.

[vincentvanhees]

@vincentvanhees I was also wondering if you remember what + 5 is for on this line? I was curious and I couldn't figure it out.

I did that to make the output empirically consistent with the R package GENEAread, which is slower but was developed by the manufacturer. Somehow my timestamps were always 5 off relative to their output. I could not figure out why.