On 2026-01-16 22:22, Berthold Stoeger via subsurface wrote:
On Freitag, 16. Jänner 2026 16:51:16 Zentralindonesische Zeit Ron
(Subsurface)
via subsurface wrote:
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.
The usual best practice is to store and manipulate the time in the
backend
as UTC, which has no political discontinuities other than things like
leap
seconds (which we also don't need to worry about in our code), and makes
relative time math easy (if there's 2 hours difference, things happened
two hours apart regardless of what local clocks said during that
period).
So *I think*, we'd have (up to) three relevant times. The timestamp_t
time
which would become either "real" UTC if the timezone was known, or
"fake" UTC
if it was not (which makes no real difference to how we handle things
now).
And then there's the 'display time', so when we show you that record in
the
dive list, we'd use the timezone recorded to always show you the time
that
you saw on your DC when you did it, along with the timezone/offset that
it
reported or you manually entered. (and in the case of our fake UTC we'd
just show the time as a literal with no timezone exactly how we do now).
And then there's the local time on the device you are looking at it on,
which may or may not be the same as the zone the dive happened in. And
it's an open question as to whether people want or we offer some way to
show the time in that zone (do you really want to know what time it was
back home while you were diving at sunrise?) - but that's the timezone
we'd default to if you were manually entering a dive - otherwise it
doesn't really come into play.
Which unless I'm missing something, should be completely backward
compatible with existing dive records. Nothing would change with them
unless *you* wanted to explicitly go back through them and add a
specific time zone to fix some historic weirdness in your logs that
irks you.
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.
Yeah, and that's really not any different to how things are now.
A sequence of dives with a timestamp_t which could be relative to any
random but unknown timezone isn't a lesser problem to one with random
but known timezones.
So we can always degrade the case of 'known timezone' to the one we
have now if there is some corner where that glitches awkwardly, but
I'm not thinking of any example right now where that would be a
newly introduced problem that we don't already have?
Maybe the case where you have multiple DC's reporting different
timezones? But even there, it's probably not (much?) different
to how we already handle drift between them? There's the raw
data each DC reported, and the one-true 'dive time' which might
be a few minutes different between them. We'd just have the
opportunity to use the TZ data to still sanely merge those
records instead of looking at them and going "hey, these two
records are an hour apart, they can't be the same dive".
Ron
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
