Difference between revisions of "Talk:Dates and Times"

From Personal Science Wiki
Jump to navigation Jump to search
Line 15: Line 15:
 
== local time requires the time zone to be correctly written too while UTC does not ==
 
== local time requires the time zone to be correctly written too while UTC does not ==
  
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.
+
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]])

Revision as of 01:42, 24 December 2021

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...) 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. - Gedankenstuecke (talk) 08:45, 9 November 2021 (UTC)

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. - Gedankenstuecke (talk) 10:31, 30 November 2021 (UTC)

local time requires the time zone to be correctly written too while UTC does not

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. DG (talk)