TimeSegments2ZeroFile parameter

[jhmigueles]

TimeSegments2ZeroFile actually expects a data.frame, and not a file path, thus the name of the parameter is confusing.

• Option 1: rename TimeSegments2ZeroFile to TimeSegments2Zero and improve documentation, while keeping the funcioning of TimeSegments2ZeroFile as it was to avoid breaking this functionality in the case it was used for others.
• Option 2: Change the TimeSegments2ZeroFile functionality so that it works with a csv file in which starting and ending of windows are provided in %H:%M:%S format. While the current functionality will be transferred to the parameter TimeSegments2Zero. In this option, I would set a check in this parameter so that if a data frame is provided to TimeSegments2ZeroFile, this data frame is used for TimeSegments2Zero and a warning is triggered to let the users know about this change.

[vincentvanhees]

I think option 2 is preferable, because that avoids having to change parameter names and broadens the functionality. I am sure people will like the option to provide files instead of data.frames but those who have used data.frame will like to keep doing so.

I assume this is not going to be an enormous time investment?

[jhmigueles]

check_params, in line 115 checks that TimeSegments2ZeroFile is a character argument and triggers an error in case it is not. This means that users were not able to provide data frames to TimeSegments2ZeroFile in the past, right? Should I skip the check on the class of TimeSegments2ZeroFile to allow for both data frames and file paths? Or should I keep the error and introduce new parameter TimeSegments2ZeroDataFrame (informing that they should be using this parameter instead)?

[vincentvanhees]

If nobody has been able to use it and nobody ever complained about it then maybe best is to remove the functionality to help tidy up GGIR. The less functionality we have to maintain the better.

[jhmigueles]

Can we be sure about that? The function might have been used before implementing this check?

[vincentvanhees]

Ok, I just looked inside the code and see that in g.part2 parameter TimeSegments2ZeroFile is actually expected to be a file, so the problem is with the parameter documentation and not with the functionality itself. It is not a data.frame that should be a supplied but the path to a csv file with the following columns:

• filename
• windowstart
• windowend

The assumption seems to be that doing as.POSIXlt(windowstart, tz = desiredtz) automatically works without the need to specify a timestamp format. So, presumably the assumption is that it follows the machines default timestamp format?

[jhmigueles]

I can try with files using time stamps in different formats and see if everything works. If so, then we only need to revise documentation, right?

[jhmigueles]

Only testing for now, I created the TimeSegments2ZeroFile using different classes (as.POSIXct, as.POSIXlt, and simple character strings with the timestamps) but the same format ("%Y-%m-%d %H:%M:%S"). Here an example:

# as.POSIXct
ts2zero = data.frame(filename = "01gt3x.gt3x.RData",
                     windowstart = as.POSIXct("2023-02-22 18:00:00", tz = "Europe/Madrid"),
                     windowend= as.POSIXct("2023-02-22 22:00:00", tz = "Europe/Madrid"))
write.csv(ts2zero, "D:/GGIRdev/logs/ts2zero.csv", row.names = FALSE)

All these formats could be read, I guess because the format of the time stamps is the same. However, if I change the format to, for example "%d/%m/%Y %H:%M:%S", then the time stamps are not correctly identified and the TimeSegments2ZeroFile is not used.

Other observations:

• In my case, using tz = "Europe/Madrid" and desiredtz = "Europe/Madrid", GGIR time shifts the segment and instead of taking from 6pm to 10pm, it takes the segment from 7pm to 11pm.
• This functionality assumes no movement in the full segment(s) specified in the file, it does not only impute the invalid time, but all the time in the segment (g.impute, line 82)
• It turns all the acceleration metrics to zero, but I would expect that EN, if available, would be turned to 1, not 0.

[vincentvanhees]

I looked into my email correspondence and see that the functional as implemented is in line with the requirements of a project I did in 2019. The main problems are:

• The documentation does not match what happens in the code => I will now prepare a revision to update the documentation.
• I seem to have made no effort to make this functionality generic beyond the scope of that project => For now I will add a warning about this in the documentation. I do not see a direct need to invest time in this, but at least it is helpful to document this for future user of the parameter.