Changes

Both above mentioned problems can be avoided when observations are timestamped not only with the local time, but also the present offset from UTC/the time zone they are experienced in. Some frequently used tools for personal science (such as the Apple Watch/Apple Health) store the data in this way, but this seems to be the exception from the rule.  

Both above mentioned problems can be avoided when observations are timestamped not only with the local time, but also the present offset from UTC/the time zone they are experienced in. Some frequently used tools for personal science (such as the Apple Watch/Apple Health) store the data in this way, but this seems to be the exception from the rule.  

If you are designing your own data collection protocol for your personal science project and you expect changes in time zones (either due to travel or daylight saving time) a good rule of thumb would be to collect the local time alongside the timezone information.  

If you are designing your own data collection protocol for your personal science project and you expect changes in time zones (either due to travel or daylight saving time) a good rule of thumb can be to collect the local time alongside the timezone information. A problem that can occur with this strategy is when the timezone information is faulty or gets lost along the way of the data processing, so one needs to be cautious when using this approach.  

 

[[User:DG|DG]] ([[User talk:DG|talk]]) NO! Store and export in UTC. Time will need to be compared (hours between naps for example) and local time will have to be converted to UTC to do this. If there is an error with TZ the data will be messed up in local time but fine in UTC. There are many ways TZ can get messed up when you are dealing with different devices. In my experience, local time is not useful except to tell the current time.

=== What is a day? ===

=== What is a day? ===