Editing Dates and Times
Jump to navigation
Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
− | + | 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 | + | |Related tools=One Button Tracker |
+ | }} | ||
===Users interested in this topic (add your name to the list below!)=== | ===Users interested in this topic (add your name to the list below!)=== | ||
Line 30: | Line 31: | ||
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 | + | 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. |
+ | |||
+ | [[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? === | ||
Line 44: | Line 47: | ||
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. | ||
− | + | {{Topic Queries}} | |
− | [[Category: | + | [[Category:Topic]] |