Dirk, you forgot the other corner case - some countries don't have fixed DST transitions.
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. Benjamin On Fri, 16 Jan 2026, 02:43 Michael Keller (catch-all) via subsurface, < [email protected]> wrote: > Tēnā koutou katoa. > > > On 16/01/2026 06:01, Dirk Hohndel via subsurface wrote: > > 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. > > > I suspect it's more than a 0.1% problem - in Australia alone there are two > popular diving areas (Mt. Gambier and Gold Coast) that each have 1000s of > dives done each year, and sit right on the border line between two time > zones (or a DST boundary for the Gold Coast). But maybe this is only a > localised Australian (and potentially Russian) problem, as for most of the > rest time zones seem to be following sovereign state boundaries, making > them less likely to be diving hotspots. > > > 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. > > > Not sure how much there is to 'get right' when it comes to persisting the > time zone information if and when this is supplied by the dive computer as > part of a dive log timestamp. This could practically even be done as 'Extra > Information', and would remove the guesswork when trying to make sense of > unrealistic looking timestamps after the fact. > > > Re multiple dive computers: My other dive computers on the Mt. Gambier > trip did not have GPS, or time zone awareness. So they reported the dive > time in the time zone where they had last been used, which was New Zealand > time. So dive computers that track time in the form of 'whatever time it > was wherever the user last bothered to set the time' are not helping to fix > this, unless the diver is meticulous enough to add 'check that the correct > local time is set' to their pre-dive checklist. > > > 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. > > > I think we are on the same page here. This is about recording what > timezone a particular dive was recorded in, not about trying to be clever > with it. > > > Sure you do, if you write "(Somewhere in) Hawaii, 16th January 2026" in > it, then you have recorded what time zone you were in. > > > This may work well for Hawaii, but '(Somewhere in) Mt. Gambier' will not > narrow it down to a single time zone. > > > Ngā mihi > > Michael Keller > _______________________________________________ > subsurface mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
