#9 Allow time to be set as UTC system time

Open
opened 6 months ago by bluepup · 3 comments
bluepup commented 6 months ago

It is always a good Idea to use UTC [1] for data logging. Some loggers will not support DST [2] and if you log beyond the date where DST occurs you may be confused or lose or misalign your data. Worse if you travel across timezones.

It is always a good Idea to use UTC [[1]](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) for data logging. Some loggers will not support DST [[2]](https://en.wikipedia.org/wiki/Daylight_saving_time) and if you log beyond the date where DST occurs you may be confused or lose or misalign your data. Worse if you travel across timezones.
kollo added the
enhancement
label 6 months ago
kollo commented 6 months ago
Owner

Well, yes. I understand but: what shoud be the effect in the App? All loggers supported here do not have their own internal clock. The start-date is set by the App (yyy-mm-dd-hh:mm:ss) and the datalogger just increases a sample counter. So if you set loal time at the bginning, you get timestamps in local time, if you use UTC, you will get utc. If there is a discontinuity (Switch to daylight saving time or laps seconds, they cannot be recognized by the logger. The app also (currently) does not correct for this. Maybe this is what you mean? Correct the timetamps after reading of the data to local time including all lapses.

Well, yes. I understand but: what shoud be the effect in the App? All loggers supported here do not have their own internal clock. The start-date is set by the App (yyy-mm-dd-hh:mm:ss) and the datalogger just increases a sample counter. So if you set loal time at the bginning, you get timestamps in local time, if you use UTC, you will get utc. If there is a discontinuity (Switch to daylight saving time or laps seconds, they cannot be recognized by the logger. The app also (currently) does not correct for this. Maybe this is what you mean? Correct the timetamps after reading of the data to local time including all lapses.
bluepup commented 6 months ago
Poster

Oh, I thought of a selector to set the loggers clock to UTC even it the phone uses a different timezone. One could do that manually by looking up the current UTC time and setting the value manually when programming the logger.
But there is the option to use "(aktuelle) Systemzeit verwenden" (translates like: use current system time) and it would be great to have a switch in the app to let it use UTC and not have to set the phones system time to UTC.

Oh, I thought of a selector to set the loggers clock to UTC even it the phone uses a different timezone. One could do that manually by looking up the current UTC time and setting the value manually when programming the logger. But there is the option to use "(aktuelle) Systemzeit verwenden" (translates like: use current system time) and it would be great to have a switch in the app to let it use UTC and not have to set the phones system time to UTC.
kollo commented 6 months ago
Owner

Ok, I understand. Well, you can set the loggers start time manually, if the check at "use current system time" is removed. Maybe for convinience the "current system time" could be specified further somewhere in the menu (as you proposed) "UTC" or "local".

Of course this would still not solve the problem if the DST changes during(!) loging.

Ok, I understand. Well, you can set the loggers start time manually, if the check at "use current system time" is removed. Maybe for convinience the "current system time" could be specified further somewhere in the menu (as you proposed) "UTC" or "local". Of course this would still not solve the problem if the DST changes during(!) loging.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.