On 2026-01-16 19:24, Robert Helling via subsurface wrote:
On 16. Jan 2026, at 09:15, Berthold Stoeger via subsurface
<[email protected]> wrote:
in adding a "std::optional<int> gmt" field to struct dive. An unset
value
You realise that in India there are time zones that differ from GMT by
half-hours? The int should be seconds not hours.
Mike's Mt. Gambier example is the same. The state of South Australia
is +1030 ACDT in Summer, while Victoria just a few miles away across
the border is +1100 AEDT.
And the mistake is apparently not uncommon. I got Insta360 to patch
the firmware of their Ace Pro when it shipped not able to cope with
+30 zones.
The Queensland / New South Wales example is even more insidious,
because they are on the same longitude and share the same coastline,
but Queensland is a fear of fading the curtains state, so through
winter they are on the same local time but in Summer, crossing that
border to the north will change your clock by an hour.
And there is no border control, you can literally do a U-turn on
Boundary St near the coast and go from heading West in one state
to East in the other.
(To be fair, the length of day change as you go further south
does really make this a very different problem for people living
at higher lattitudes than those living north of the tropics).
What we probably need is something that can let us record either
the political timezone (like what you see in /etc/timezone to set
your system local time) or an absolute offset, like you might see
included in an ISO 8601 timestamp with no other context or political
zone information.
There is existing best practice on *how* we should handle this, so
we should look to that, and not try to reinvent it, *if* or when
we decide the time is right for us to worry about this more than
we already do.
Ron
(who is trying not to bikeshed the details, but just wanting us
all to have a clear picture of all the considerations involved.
It's ok to disagree on the relative severity and the number of
people various actions affect and what the triggers for further
action might be because those things are a bit subjective.
Being *in* the 0.01% gives you a different view to worrying
about the 99% - but this is one of those oddly brainmelty
problems where it's mostly simpler than you think if you do
Handle It Right, but quickly becomes a lot more complicated
than you think if you don't quite.
So it's much more important that can we define and agree on
the issues involved correctly, than that we agree on what,
if anything, we should do about it now, or later if the facts
on the ground about how many users it affects provably change)
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
