1,711
edits
Changes
→more comics from the internet about this problem and how we shoudl always use linux epochs: new section
: I agree that storing data ''just'' in local time, without any TZ information is a really bad approach to take and should be avoided at all cost. The approach of storing in local time alongside the TZ information is still relevant, though I think the risk of somehow losing the TZ information when using the approach of storing data in local time + TZ information is a real issue that can occur. But for many analyses the actual local time is what people are actually interested in. Sleep timing (including naps), diet timing strategies, physical activity etc. are mostly based on local time. But again, all of these local times should also include the TZ. - [[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]]) 10:31, 30 November 2021 (UTC)
: I agree that storing data ''just'' in local time, without any TZ information is a really bad approach to take and should be avoided at all cost. The approach of storing in local time alongside the TZ information is still relevant, though I think the risk of somehow losing the TZ information when using the approach of storing data in local time + TZ information is a real issue that can occur. But for many analyses the actual local time is what people are actually interested in. Sleep timing (including naps), diet timing strategies, physical activity etc. are mostly based on local time. But again, all of these local times should also include the TZ. - [[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]]) 10:31, 30 November 2021 (UTC)
"risk of somehow losing the TZ information" more like misaligning and then there is the daylight savings time. INternally the data should be stored in the safe from bugs way but user can request is sent out in the easier for them to read way. Encapsulation etc. APIs should give out UTC though for sure. [[User:DG|DG]] ([[User talk:DG|talk]])
"risk of somehow losing the TZ information" more like misaligning and then there is the daylight savings time. INternally the data should be stored in the safe from bugs way but user can request is sent out in the easier for them to read way. Encapsulation etc. APIs should give out UTC though for sure. [[User:DG|DG]] ([[User talk:DG|talk]])
The actual storage is always in offset linux epochs to save resources. Right? And envelopped wrapped output is in more human readable format including local time if they ask. But API machine to machine i always not local time.[[User:DG|DG]] ([[User talk:DG|talk]]) 01:49, 5 January 2022 (UTC)
: For most devices and apps it's really unclear how they internally save the timestamp information as one can only see how they expose the data APIs or data export formats. In those cases it can be any of the options I listed on the page (e.g. Fitbit does local time, no TZ info while Apple Health stores local time + TZ information). - [[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]]) 14:14, 27 January 2022 (UTC)
:: How could they possible be so badly designed!? miband gives utc!! [[User:DG|DG]] ([[User talk:DG|talk]])
== time in seconds since 1970 aka linux epochs ==
To save space, Mbient labs records time in seconds since start of recording. The Mbient app exports data time represented as seconds since 1970; basically linux epochs. This is easier to parse, see the '[https://lubridate.tidyverse.org/ lubridate]' R package. If the CSV file contains errors or complex quote in quote or strings with many special characters like URLs the problem becomes more complicated *(and so easier parsing is needed). When I analyze the data some functions can not work with class time-date so I am forced to convert time-date back to seconds. This may not apply to all statistical analysis tools but they all internally hold time date as something much closer to a double or integer than a character string.
: The unix epoch still has the problem of not being aware of TZ at all right, so depending on what you set on the device as timezone it might be UTC or something else though? - [[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]]) 13:49, 3 June 2022 (UTC)
:: TZ is basically very general location. Do you need every device tracking it? TZ is not as good for health issues as weather esp sun set sun rise. [[User:DG|DG]] ([[User talk:DG|talk]]) 00:50, 4 June 2022 (UTC)
:: https://en.wikipedia.org/wiki/Unix_time the time zone is UTC or practicaly none at all.
== more comics from the internet about this problem and how we shoudl always use linux epochs ==
https://xkcd.com/2562/