Changes

1,962 bytes added ,  08:08, 1 October 2022
Line 14: Line 14:  
  "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]])
   −
== local time requires the time zone to be correctly written too while UTC does not ==
+
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)
   −
so local time definitely introduces extra opportunity for errors. imagine if user flies over time zones or daylight savings time and device fails too change its time at the correct moment....! and then the daylight savings time will make overlaps too. [[User:DG|DG]] ([[User talk:DG|talk]])
+
: 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/
1,685

edits