Editing Talk:Dates and Times

== No lead? ==

I expect articles to have a "lead" paragraph prior to the table of contents on the page. (I'm not sure if this is a product of the template used to start pages; that might be inadvertently resulting in this...) [[User:Madprime|Madprime]] ([[User talk:Madprime|talk]]) 13:47, 8 November 2021 (UTC)

: Yeah, it's a result of the template where the form data goes all either into the info-box or below the ToC. I'll move the first bits manually above the ToC as a lede. - [[User:Gedankenstuecke|Gedankenstuecke]] ([[User talk:Gedankenstuecke|talk]]) 08:45, 9 November 2021 (UTC)

== What is so complicated? time is UTC or Unix Epoch and timezone is just worse location ==

Time zone is just a worse location. If all companies use UTC or LE there are no problems. This wiki page points out how much effort computer programmers put into preventing bugs and then how much bug potential not using UTC/LE makes. https://www.explainxkcd.com/wiki/index.php/1883:_Supervillain_Plan
Avoid companies that export dates and time in local time as many other issues will crop up.

== 2. Saving all data in local time of recording ==

This is not an option; if something goes wrong with timezone the local time data is fricasseed or will require lots of debugging but UTC does not let this happen. The more a person is a health tracker the more its likely that they have geographic location in their stack or at least a good source for TZ. More over converting to local time has next to no purpose; QSers track their sleep, and those that care have devices that track their lumens exposure. Those that care about weather use either a weather station or geographic location.  There is no point in converting to UTC unless its editing some manual entry within an hour. https://www.explainxkcd.com/wiki/index.php/1883:_Supervillain_Plan
Avoid companies that export dates and time in local time as many other bugs will certainly crop up.
All errors have to be found and at least acknowledged or even found and fixed that is a lot of work. The benefit of local time is that all the data can be read by hand but almost none of this data will be and even then its not hard to write in a single line to display in local time. -- [[User:DG]]

: 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]])

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/