New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timezone question #301
Comments
I'm not sure what the issue is? The reason to use zulu time is that you can always convert a zulu time to the local time zone. See e.g. the timezone package. |
When the data is still on the phone you can convert it back to local time. However, when the data is exported away from the phone, this is harder for the researcher. Moreover, it is exactly then that we need to convert it back to local time, for example to link it with other external data (e.g. ESM questionnaire data or data from other sensors and other apps that save entries in local time). The problem is that you don't know the local time zones of all participants. For example:
When you are also gathering locating during the study, you probably could infer the time zone. In some studies we however will not want to gather location data (e.g. for privacy reasons). |
ok - I understand. My main problem with this PR is that the I know that you probably do not use the CARP backend. So I will look for another solution to this problem. |
I will add a new data type for time zone - this is IMO the best solution. Also need to collect it on the phone. |
In CAMS v. 0.40.13 you can write a protocol that include collection of time zone information. Examples include:
And you can also add it to an
|
Thanks! This seems to work. |
Is there a way to add the time zone of the participant in the header? The time in the header (at this actual moment) reads
"start_time": "2023-01-07T20:24:52.266973Z"
But it is 21:24:52 here and I am not in Zulu time zone (but in Alpha time zone aka UTC+1). Its fine if the start_time is just in UTC time, but it would be nice if another field would give the time zone of the participant.
The text was updated successfully, but these errors were encountered: