Not that anyone appears to care - but I repeat what I have said about five times in this thread.
I don't want us to add support for time zones. I don't want us to add any of this complexity to our code. I don't want to see how the code deals with having multiple dive computers that may or may not have time zone data, have different time zone settings, or whatever. If your personal happiness depends on knowing what time zone your dive computer thought it was in, add it as text in the extra info. But do not start adding two (or more) conflicting time stamps to every dive. I'll walk away from this conversation as it is bad for my mental health. /D > On Jan 24, 2026, at 13:17, Berthold Stoeger via subsurface > <[email protected]> wrote: > > On Samstag, 24. Jänner 2026 22:03:08 Mitteleuropäische Normalzeit Michael > Keller wrote: > >> On 24/01/2026 22:18, Berthold Stoeger wrote: >>> For example my old dive computer reported this value. Otherwise I would >>> say >>> it's a UI issue. One could default to local time offset or to "unknown". >>> Also, the user should be able to edit this value, obviously. >> >> The user being able to edit the value is an interesting one > > I think this is a must. In particular, if we start extracting timezone > information from the divecomputer we have to give the user the chance to > "fix" > old and also new dives. > >> - while this >> is definitely a good thing for the timezone offset stored for a dive, I >> also think there is value in retaining the information provided by the >> dive computer as much as possible, to give the user a way to go back to >> what was originally reported, even after they have edited and >> potentially merged dives. > > Fully agree. But IIRC, we don't yet have a place where we display dive- > computer specific data (expect extra_data), or do we? > > So I understand your intent of storing this in extra_data, but I would prefer > doing it in a more structured way. See my (extremely early and rough) > PR#4690, > where I started adding a datetime_t type with an (optional) offset_to_utc. > > Maybe we can rename the "Extra info" tab to "Dive computer info"? > >>> If we have an offset to UTC, then of course we should use that directly. I >>> was thinking about extended "this country with active DST" kind of >>> information that should go into extra_data. >> >> From looking at the Garmin backend, and having a quick glance at the 4 >> or 5 other backends that support a timezone offset, they all seem to be >> providing 'seconds offset from UTC' only, and no more detailed timezone >> information. > > Cool, great - That makes absolute sense to me. > > More detailed timezone manipulation should be relegated to the UI. In the > case > that somebody even wants that (doubtful). > > Berthold > > _______________________________________________ > subsurface mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
