search

wadpac / GGIR

Code corresponding to R package GGIR
https://wadpac.github.io/GGIR/
Apache License 2.0
94 stars 60 forks source link

g.part5.wakesleepwindows fails at rounding timestamps to seconds #1192

Closed jhmigueles closed 1 week ago

jhmigueles commented 2 weeks ago

This is a minor bug that very rarely occurs but it has an easy solution. In g.part5.wakesleepwindows, the function round_seconds_to_epochSize makes the timestamps from the sleep period time derived in g.part4 compatible with the epoch size that is being used in g.part5. If the rounded seconds equal 60, then this function should add 1 minute to the timestamp, but instead a timestamp such as 9:12:60 would be produced. Then, the function findIndex is not able to match the 9:12:60 timestamp to the timestamps in the time series, and the indices for that specific night are wrong.

vincentvanhees commented 1 week ago

Could you please document in this issue what you mean by "... and the indices for that specific night are wrong."

jhmigueles commented 1 week ago

How wrong are they? Just one minute offset or entirely different hours in the data? We need this information to communicate to users how severe this bug is.

When the function findIndex within g.part5.wakesleepwindows is not able to match the wake or sleep timestamp with the timestamps in ts, then the next lines are run:

if (is.na(s0) == TRUE) {
      s0 = 1
    }
if (is.na(s1) == TRUE) {
      # might still be NA if the timestamps is not in ts (expanded time from expand_tail)
      # if so, we assume the participant is sleeping at the end of the recording, this night will be disregarded later on
      s1 = nrow(ts)
    }

This means that, if the missing timestamp corresponds to sleep onset, then all the data from the beginning would be classified as sleep period time, which is problematic especially if it is not analysing the first night in the recording because a substantial part of the recording would be classified as sleep period time. This is what it was happening to some of the files in my dataset.

If the missing timestamps is a wakeup, then all the data from that sleep period time until the end of the recording would be classified as sleep period time.

Does GGIR generate any errors or warnings? If not, how did you discover?

No, GGIR does not generate errors or warnings. I observed that many of the files in my dataset were available in part2 reports but not in part5 reports. These files had nonwear, but still they had some wear data that should be sufficient to appear in the part 5 reports, so I started investigating this.

vincentvanhees commented 1 week ago

Thanks, maybe good to add that this is the specific combination of using timestamps with 60 seconds in character format and as.POSIXlt. For as.POSIXct("2024-9-2 10:10:60") this is not a problem because it gives "2024-09-02 10:11:00 CEST".