On Sonntag, 18. Jänner 2026 21:08:36 Zentralindonesische Zeit Michael Keller via subsurface wrote: > Tēnā koutou katoa. > > > On 16/01/2026 21:15, Berthold Stoeger via subsurface wrote: > > >> Some of us live in countries where the DST transition changes every year > >> for "reasons", and then you get the lovely corner case of needing to > >> keep > >> these historical changes, so that you can see when exactly you are > >> adding > >> or subtracting that rather useless extra hour to your date/time. > > > > 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. > > > I think this should rather go into struct divecomputer - or go in there > _as well_, as the reported timezone is specific to the dive computer. > And 'diving with more than one dive computer' should be the norm for > technical diving, and not an exception.
Please observe that I am _not_ talking about full timezone or DST information. I am talking about the offset between local time and GMT/UTC at the start of the dive. This datum is well defined and stable, albeit potentially unknown on import. It belongs to the dive and combining dives with conflicting data should throw an error. I would suggest placing full timezone/DST information, as provided by the divecomputer, in extra_data. Berthold _______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
