Changes

Virtually all data one might want to collect as part of doing personal science have some form of timestamp associated with it – that is: When was the data collected? Unfortunately handling dates & times isn't as straightforward as one might assume and the problem of correctly doing so is often only half-jokingly called one of computer sciences hardest problems. Why are dates & times hard? There's [https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones/ many reasons], including traveling across timezones and daylight saving time.{{Topic Infobox

Virtually all data one might want to collect as part of doing personal science, has some form of timestamp associated with it; that is, the moment when the data was collected. Unfortunately handling dates and times isn't as straightforward as one might assume. The challenge of correctly doing so is often only half-jokingly called "one of computer science's hardest problems". Why are dates and times difficult to catalog? There are [https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones/ many reasons], including traveling across time zones and daylight savings time.

===Users interested in this topic (add your name to the list below!)===

===Users interested in this topic (add your name to the list below!)===

[[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]])

[[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]])

While this makes the storage and calculation of correct times relatively straightforward it becomes impossible to reliably calculate the actual local time at which the data was collected when changes in time zones start to come into play.  

While this makes the storage and calculation of correct times relatively straightforward it becomes impossible to reliably calculate the actual local time at which the data was collected when changes in time zones start to come into play.  

E.g. In the simplest scenario half of your data will be off by one for data recorded during daylight saving time but displayed when being in standard time and vice versa. Things get even more tricky if you travel or move between time zones. For all of these cases the only way to reliably calculate the local time is by knowing the geographic location for each observation.

E.g. In the simplest scenario half of your data will be off by one for data recorded during daylight saving time but displayed when being in standard time and vice versa. Things get even more tricky if you travel or move between time zones. For all of these cases the only way to reliably calculate the local time is by knowing the geographic location for each observation. If

you have reliable geolocation information for yourself, then consistently storing all data in UTC might be the easiest approach, as you don't have to handle different timezones when merging data.

==== Data in local time ====

==== Data in local time ====

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.  

=== What is a day? ===

=== What is a day? ===

It can be important to understand this distinction both when comparing different sleep metrics to each other, in order to compare data from the correct dates but also when trying to understand how sleep might affect other variables. Not understanding for which day the sleep is recorded can easily result in being off-by-one.

It can be important to understand this distinction both when comparing different sleep metrics to each other, in order to compare data from the correct dates but also when trying to understand how sleep might affect other variables. Not understanding for which day the sleep is recorded can easily result in being off-by-one.