search

wadpac / GGIRread

Functions for reading accelerometer data files
https://CRAN.R-project.org/package=GGIRread
Apache License 2.0
5 stars 3 forks source link

Minor correction of timestamp handling code in readGENEActiv #55

Closed l-k- closed 5 months ago

l-k- commented 5 months ago

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[bot] commented 5 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

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

Additional details and impacted files ```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

l-k- commented 5 months ago

@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 commented 5 months ago

@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.