There is a long and detailed discussion on how Subsurface uses timezones on
GitHub - which kinda sucks because that discussion is now locked away in a
proprietary platform. I had been hoping to summarize it here, but it's gone so
long now that that seems really hard. Instead I'll move the last comment to
here and continue the conversation here and point people directly to the issue
on GitHub if they want more context:
https://github.com/subsurface/subsurface/issues/4680
(and yes, the issue touches the broader "port QML code / Subsurface-mobile to
Qt 6" challenge...)
> On Jan 15, 2026, at 08:16, Ron wrote:
> There are a couple of hard lines that matter to me in the way the mobile app
> works
>
> There shouldn't be any big surprises there, I've tried to stick as close to
> the original spirit as possible and not change anything gratuitously.
>
> The custom theming is gone, at least for now - it doesn't really fit in with
> being able to respect the users choice of system dark/light theme - but we
> might be able to bring that back if/when the Kirigami "union" pipedream ever
> lands. It's supposedly going to Fix Everything about theming - but we'll see
> what really happens when that is really real.
>
The one person who loves the pink color scheme that I added as a joke will be
sad 🤣
> And the toolbar Action menus look different to how they used to, but that's a
> change Kirigami forced on us. The left/middle/right thing is gone, now it
> just fits as many things as there are room for and puts the rest in a context
> menu - but I haven't done anything to significantly change that menu
> structure otherwise. There's a few things we probably should look at, like
> the location submenu, which only has one option in it - but that's stuff we
> can talk about after the Necessary Changes land and easy to fix later so I
> haven't taken any liberties with stuff like that.
>
I love updates that make things "better" meaning "different" meaning
"surprising to users". Oh well.
> And there's the question of whether we drop support for Diveshare (#4644
> <https://github.com/subsurface/subsurface/issues/4644>), but I haven't done
> anything to act on that yet either until someone who Knows clarifies its
> status.
>
Yes we should. Clearly dead.
> There's a few new settings knobs, mostly for things that we were using
> somewhere but not letting you actually set in the mobile version, and I've
> just rehashed the Dive Summary page to let you pick arbitrary intervals to
> show those stats for, partly as a test bed for getting a better handle on
> issues with handling dates, but also because it's just a useful extension to
> that which was easy to add.
>
I'm not sure what you mean by that, looking forward to seeing this.
> We can export and import XML files now (including saving them to the local
> file system), because Android mechanisms for that are convoluted, but not
> quite as nasty and restrictive as they were looking to be for a while in the
> past, and that was kind of a spin off benefit to getting the email support
> working.
>
The challenge with this is that the APIs for this changed at least three times,
and we have people using the Android app on positively ancient versions of
Android (at least one user I get occasional email from on Android 7). But if
you have something that works, that's a very frequently requested feature -
even if it doesn't work on all Android versions, it might be worth while.
> There's lot of behind the scenes stuff to get pages to lay out correctly and
> some simplification of how that's done, and some small changes to exactly
> what controls are used to do what, and what signals they are connected to so
> that everything which needs to actually gets updated when things are changed,
> but that's more about getting it to do the same thing in much the same way
> but more reliably or robustly or easily, than about changing how it looks or
> acts from a user perspective.
>
> My actual changelog notes are much much longer than that, but that's the
> general sense of their landscape.
>
> Oh and there's an open question about what architectures we're going to build
> the mobile app for. Right now I'm only building it for arm64, and Qt 6.10
> only gives us support back to Android 9. Are there any Android 9+ devices
> running on armv7? And are there x86 devices that would rather run the mobile
> than the desktop version? But again, we don't need to answer that before I'm
> done.
>
I believe Android on x86 is dead as a doornail. I was at Intel when that pipe
dream was laid to rest a decade ago. Sure, I even have two x86 Android devices
in a drawer (no idea if they would turn on), but that's... not something I
worry about. We have only had arm64 binaries for quite a while now.
As I said above, there is an Android 7 user - and I'm not sure if they can use
the current binaries, I checked my email and haven't heard from them in a
couple of years. Android 9 came out in 2018, phones and tablets older than
eight years are likely getting challenging to keep going. I have older ones,
but none are in use. And a lot of the devices sold in 2016 and 2017 received
Android 9 upgrades...
> QString is without doubt an awful abomination - but the only thing worse is
> repeatedly converting things to and from it, in code that is only ever used
> with some other Qt thing that expects or returns them. So there's probably
> some long term benefit to clearly defining what if anything should remain C
> code, what is C++ but might genuinely be reused outside of a Qt context, and
> what code really is tainted by always eventually needing to do things the "Qt
> way" and should just accept and work that way. But that's also a broader Job
> For Later, and not something this patch set should scope creep into except
> where it was going to need to rewrite that code anyway for other reasons.
>
> This is one thing where a couple of our excellent C++ programmers (@bstoeger
> <https://github.com/bstoeger> , @mikeller <https://github.com/mikeller> , a
> couple others) have gone through many iterations of trying to figure out
> where to use std-C++ stuff and where to stick with Qt. And I'm not sure we
> always got that right.
>
> Yeah, I think there's a few places that might have gone a bit too far. I'm
> all for using not pulling in framework stuff where it really isn't needed or
> adding value, but there's a few things that look like they got "un-Qt'ed" but
> aren't ever actually used with any other code except Qt, so there's lots of
> otherwise unnecessary translation going on between them. But I've avoided
> scope creeping into that where it wasn't something I had other reasons to
> need to rewrite too - I figure that's something we can talk about intent and
> direction later too.
>
I don't have strong opinions here - I find std-C++ even more unreadable than
most other C++ code. All I want to point out is that there are others here who
do have strong opinions.
> Linus and I are the two big C holdouts that typically like that code better
> and typically groan when yet another piece of perfectly good, perfectly
> working, perfectly simple C code gets turned into a convoluted, complex and
> (to me) often unreadable C++ mess. A lament that our C++ developers have
> gotten tired of hearing a long time ago...
>
> Heh, I'm happy in both those spaces as big Right Tool For The Job advocate. I
> wouldn't want to write kernel drivers in C++, but some of the attempts at OO
> C (outside of the kernel where that's actually done quite nicely) equally
> look rather strained and uncomfortable. Good C++ code shouldn't be unreadable
> for anyone with a good grasp of C, though some of the newer idioms are
> starting to stray further from that. (and yes I have been killing 'auto' with
> great prejudice anywhere I stumble over it with an excuse to - there are a
> few cases where it can be useful, like lambdas, but I hate the extra work it
> makes me do to understand the code where the type is known and fixed, and the
> hole it pokes in the strong typing protections you were using C/C++ for in
> the first place). We have typedef for when you don't want to repeatedly type
> some horrible long namespaced template type over and over and over.
>
You are better than me, then. I find a LOT of C++ code just incomprehensible. I
think it's age and early onset dementia. Or the code is just terrible. Or it
could be both.
Some of our C code stems from the initial GTK version of Subsurface (yes,
that's where we started), and so there may still be C-style OO code somewhere.
> There might be some call for Yet Another Directory Reshuffle - just due to
> the way Qt/cmake has evolved to prefer building QML modules, but I'm trying
> really hard to avoid doing that as part of this set, even if it means
> creating a few more 'internal' modules in the interim than we will ultimately
> want to have.
>
> Is that the right call? Since you are going to change fundamentally how the
> QML code integrates with everything else, it may be easier to just do it
> right in a different directory?
>
> I've been putting it off at least until I'm through with culling intermediate
> things that we really don't need and have a full list of exactly what needs
> to be built into a QML module for the mobile builds. There's a few things
> that get built into an ordinary library for the desktop builds but into the
> QML module backing library for mobile builds. Once I know what the final big
> picture of that looks like I'll be in a better place to recommend what if
> anything we should rearrange and how. For the moment it's still a bit of a
> game cut and move one piece at a time, then audit all the code affected by
> that before moving onto the next piece.
>
That's fine. I'm just trying to say "please don't shy away from moving stuff"
if that makes it easier. Since we'll break everything and not allow Qt 5
builds, anyway, we might as well simplify things for the future.
> Either way, I've been using Subsurface for a long time now, and have every
> intention of doing so for a lot longer, and I'm doing this to scratch my own
> long term itches as a diver using it, not to pad my CV with "projects I've
> sent patches to", so I do hope you'll like the liberties I've taken with
> getting this to work and this is something I can help with into the future. I
> can't really say that Qt/QML is my Happy Place that I'd Rather Be Programming
> in, but sometimes you draw the short straw and just have to work with what
> you've got as best you can to have the nice things that you ultimately want.
>
> And here I was hoping we finally found a devoted QML person... I'm often
> wondering if those actually exist...
>
> If it's any consolation, the other diving related Favourite Tool that I've
> found myself finally drawn into scratching my own itches with is Kdenlive, so
> I'm unavoidably up to my neck in Qt and QML there too ... so I might not say
> 'devoted' so much as maybe "cursed with the burden to carry" - but hey, it
> could be worse. It could be python. Or actual Java.
>
Excellent. So not a QML fanboy, but a QML victim with experience. Works for me.
And hey, I used to hate Python and with Python 3 I have gotten to the point
where I actually write more Python than C/C++ code.
> And there's that thing they say about needing to walk in the darkness to
> really appreciate the light ;)
>
> No, the time handling and lack of timezone handling and the trade-off with
> incorrect time deltas is very very well considered and the right way to do
> things. Linus and I were on a dive trip when you sent this and spent another
> hour walking through this to re-validate our conviction that that is correct.
>
> I think I can agree with "sufficient" (if none of the rare corner cases
> become more real more often than they have to date), but I'm not quite sure I
> can get to "correct".
>
> But I'm also ok with Sufficient if you all are until we have some real
> reports of real cases where it really isn't.
>
We can agree to disagree here. And yes, I realize that I offended Michael (from
a different GitHub comment):
> On Jan 15, 2026, at 01:18, Michael Keller wrote:
> > Dirk wrote:
> Again, academic problem. We log start time and duration.
>
> I think it is a bit rich to call the diving that I actually did, and the
> problems that I actually encountered 'academic'.
>
I apologize for calling your life academic. However, calling it a 0.1%-er
problem might appear equally offensive. Among our 35+k users, this is not an
issue that people encounter.
> Compare this with what you would write in your paper log book: you don't
> write down zone zone data and what you have written does not automagically
> change when you get on a plane or change the time on your watch.
>
> So say I do the first dive at 10 am with a duration of 1 hour, and log it.
> Then I drive to the next dive site for 30 minutes, and do another dive. Then
> I log this dive at 10:30 am, just because the second dive site is in a
> different timezone.
>
> Of course, nobody in their right mind would ever log it this way in their
> paper logbook - we'd simply assume that both of the dives were done in one
> time zone, likely to be the one that we got up in in the morning.
>
> But if you are using a dive computer with GPS that automatically reports the
> dive time as local time in the dive location, then Subsurface will log this,
> forcing the user to do a forensic investigation a few months down the track
> to figure out why their dive log looks like complete nonsense. Having a time
> zone associated with the logs where the dive time was set to local time by
> GPS will help avoid this.
>
There is no way to get this right. And if you dive with multiple dive computers
(as I know you do sometimes) you'll end up with different values and for that
situation you'll simply have to manually fix it in your dive log. I will be
very very resistant to any attempt to force timezone handling into our dive
list time stamps.
Back to Ron's message:
> Right now the sweet spot seems to be using just a few of the core things from
> Kirigami
>
> I'm almost sad to hear that. But I'll also defer to your decision there...
>
> We'll see what their next round of Breaking Stuff on us looks like. If the
> bits we're still using become more of a burden than a help we can still
> reevaluate replacing them later.
>
Every time I chased down the next of their breaking changes, I wished I had
instead designed Kirigami out of Subsurface. And we are at least of round five
of this.
I'll defer to you, but my vote is to get rid of using Kirigami if at all
reasonable.
> And our tangle of overlapping C/C++/Qt/QML is nothing compared to the
> byzantine horrors of the constantly changing intersection between The Google
> Way to build cmake stuff on Android, The Qt Way to do that, and The KDE Way
> to do that - it being especially hilarious because Qt copied what KDE
> developed, but then changed it incompatibly and didn't cleanly bubble those
> changes back down, then Google copied Qt's effort but also changed it
> incompatibly, and then added their own second implementation which was
> incompatible with their first one - but then decided that their New
> implementation was just fundamentally busted, and with people already using
> it they couldn't remove it, so now their New implementation is deprecated and
> everybody is instead recommended to use or migrate all future work to the
> "Legacy Implementation" which they likewise can't now rename again either...
>
> I think I need a map to parse that paragraph...
>
> I needed to write a Makefile dependency graph to plot a course through it
> that successfully builds all of our needed deps.
>
Well, there is that. Oh, have you played with MobileOnDesktop? That adds
another layer of joy to it.
> That's the real crux of this aspect of it, we can't guarantee that doing this
> will cleanly round trip.
>
> Actually, we can. Again, you need to keep apart academic corner cases and
> what you will actually see in real life. Dives do not start between 2am and
> 3am on one of two Sunday mornings of the year. My privacy terms prohibit me
> from searching through the dive data of a good 35 thousand users, but I will
> bet a fair amount of money that there is not a single real dive in there
> where there is any issue with mapping things to and from UTC.
>
> My dives aren't in there, and yes it's not exactly on one of the offending
> days, but this is a very real start time from a very real dive I did: Tue 8
> Feb 2022 2:13 am
>
> It's why I wanted dive time stats, to see how many more of those are in
> there. We started diving at sunset that night and spent 5 hours in over two
> dives before packing up and getting home just before sunrise. I remember that
> one clearly because among other things, we ran into a massive bobbit worm out
> in the open fighting with a crab ...
>
> But again, I don't profess to be Usual ; )
>
And I repeat what I said in my apology to Michael above. It's a 0.1% problem.
I'm sure someone will be happy to start a dive at 2:30am (first one) this year
on the day DST jumps back in your place on earth (which of course isn't the
same for everyone). And I'm sure one of you will be willing to start a second
dive at 2:29am (second one) that same night, just to prove that Dirk is an
idiot. Look, I make it easy for you. I KNOW that I'm an idiot. HOWEVER. That's
not what the typical Subsurface users do. I also believe that our code will
fail when someone tries to import the world record scuba dive. 14 hours, down
to 1090ft or 333m. I have no interest in making Subsurface do everything right
for that dive. Nor for all of the other theoretically (and practically)
possible dives.
> It does mean we need two interfaces for anything shared by both sides (one
> converting TZ, the other not), and people working on that code need to use
> the right one in the right places, but that's still a lot more manageable
> than parsing strings with a near infinite number of local and customisable
> format conventions, and more user-friendly than getting people to type them
> in freehand without error.
>
> Just introduce a nice class that manages all that.
>
> Yeah, an overloaded function will be enough, so I'm not too worried about
> handling this in practice.
>
> It's perfectly representable as UTC, but once we're in LocalTime space for
> Javascript/QML, the Cleverness detects that 2:30am is not a time that ever
> actually existed and tries to Fix It. We have some control over whether it
> fixes it by rolling forward or backward (or just failing completely), but no
> option to specify "we know what we're doing, just leave it alone". And once
> it does that, it's now also a valid 'UTC' date, so the round trip back
> doesn't undo that damage.
>
> But since the UTC time is the actual time you were diving as local time, we
> go back to the fact that real people don't dive at 2:30am the day DST changes.
>
> I can assure you that I am in fact very real, and that April here, if not
> also October is often still quite divable at night even for people less keen
> on the cold than Wim Hof!
>
> But again yes, I don't pretend to be Representative in this :D
>
> And/when if we do ever fix this, I promise I will do a dive in that window on
> one or both of those nights and send you the footage, just to leave no doubt
> that it was All Worthwhile!
>
We are bouncing rubble at this point. You all are right, I am wrong. I am still
not changing my conclusions.
> I think the future will eventually be owned by devices that do get this
> right, so we probably do need to plan for that, but I totally understand
> where we came from and why it is like it is, and why (like 32bit time_t!)
> it's not going to be trivial to change.
>
> No we don't. Because I STILL don't want the dive list to say that my dives in
> Japan were 8 hours later than they actually were.
>
> I feel there is still some confusion on this particular point. I'm not at all
> suggesting that your dive list should (by default) show the dives you did in
> Japan with the time remapped to your current local timezone. It should show
> them in JST (if that's what your devices were set to) at exactly the same
> time it shows them now. The only difference is we would know they were in JST
> (and could calculate time relative to that correctly) instead of having to
> guess.
>
> Something like this: https://inaturalist.ala.org.au/observations/136613080
> Note the 'observed time' there is reported as 10:27 AM WITA. The time it
> happened in the place it happened.
> It's not reported in terms of my current local timezone. It's the time the
> people who were there were in the water.
>
> So I can be swayed by "this is going to be really ugly to implement and
> deploy and the benefit isn't worth the cost" - but I think "it's going to
> show the Wrong time in my dive list" is a misunderstanding of how a 'timezone
> aware' log would and should work.
>
Your dive computers will give you different data when you download these dives.
And the software needs to pick something. The Subsurface cloud contains more
than a million dives without timezone and as of today while there are dive
computers that do, indeed, support time zones, they still all allow you to
extract the dive start time (and that's the only thing we care about) in "local
time". And if a dive computer returns UTC plus timezone offset, that's fine,
too.
> Sorry if I sound grumpy, but we deal with insane complexity in a lot of
> areas. Let's please not go chasing for more
>
> No, it's cool, I'm glad to hear you talked this through again with Linus, and
> are asserting what you concluded from that. And I really don't want to push
> it until you are actually grumpy about it. So I can totally agree with "this
> is not our biggest problem right now", but I'm a bit less confident than you
> are that it will never be a problem.
>
Oh this discussion has run way, way, way into me being grumpy...
> I've ran into this when diving in Mt. Gambier.
>
> For the folks who don't know Mt. Gambier, it's not like the hypothetical case
> of crossing the date line. You really could be diving within walking distance
> of a 30 minute timezone boundary that devices know and respect. You could
> even not unplausibly start and end your dive in a different time zone.
>
> Compare this with what you would write in your paper log book: you don't
> write down zone zone data
>
> Sure you do, if you write "(Somewhere in) Hawaii, 16th January 2026" in it,
> then you have recorded what time zone you were in.
>
Funny you should say that. Because that's what YOU write in your logbook.
Through providing support for people's problems with the Subsurface cloud I
have by now seen hundreds and dive logs. And there are plenty of people who
have dive log entries that record as location "Paradise" -- and I have
personally be to a dive site of this name in three different countries... so
yeah, plenty of dive logs have absolutely no indication of timezone.
OK, this was painful. But at least now we have SOME of this on the mailing list.
/D
_______________________________________________
subsurface mailing list -- [email protected]
To unsubscribe send an email to [email protected]
