Failure recognising numeric participant ID numbers that are accidentally stored with decimal places

[vincentvanhees]

Problem

A user accidentally stored the participant ID number in the sleeplog with decimal places (144.00 in the example below)

which are not shown by Excel

causing that the sleep diary for this person could not be matched with the accelerometer file ID (144).

When I open the csv file in Excel and save it without making edits, the decimal places disappear:

and the sleep diary is successfully linked to the accelerometer data.

Proposed solution

I would hope that most GGIR users notice this and resolve it themself, but it is concerning that this can happen.

My first idea for a solution was to let GGIR code attempt to interpret ID as number and if it is possible check that there are no decimal places. This would come with the disadvantage that IDs with intentional decimal places are no longer permitted.

Instead, I propose:
At the end of processing the sleeplog let GGIR store the full list of IDs that could not be matched in a text file and display a warning message in the console with a reference to the text file.