On Freitag, 16. Jänner 2026 16:51:16 Zentralindonesische Zeit Ron (Subsurface) via subsurface wrote: > On 2026-01-16 18:45, Berthold Stoeger via subsurface wrote: > > > I don't see the problem. You just save GMT+x at the time of the dive. > > That's > > precisely what my old dive computer stored. > > > > It appears to be a bit of a project, but I don't see the fundamental > > problem > > in adding a "std::optional<int> gmt" field to struct dive. An unset > > value > > means "don't know" a value in the range -12 -> +14 gives a known > > offset. One > > obviously has to think about the semantics of the time when the field > > is set. > > > That's the kind of first step I was thinking. Just store the data if we > have it. We don't have to commit to any irreversible change, we just > need to not discard data which we did have to have every possible option > remain available to us.
I agree - If the dive computer provides this information it should be stored and also made editable. The crucial question to answer then is: If the time-offset field is set, is the time of the dive given as local time or with respect to GMT+0? Intuitively, I would think the former. For a potential next step, I would suggest making the time-fields internal to struct dive and access the data using accessor functions. Things obviously become sketchy if time-offset information is known for some but not for other dives. Then for example the order of dives is ill-defined. However that should come as no surprise - if your data is inconsistent, expect funky results. Berthold _______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
