Time zones (again)

[Robert Helling]

Hi,

it seems, with the planner, we ran into a time zone problem, again. So I would like to solicit some advice.

As I understand, the situation is as follows:

* Subsurface is nominally time-zone agnostic. That means we to to keep track of time zones. All times (as displayed to the user) are supposed to be “local time”. This does not mean local time of the computer we are running on but rather local time at the place and time of the dive (i.e. the time displayed by the diver’s watch when she jumped into the water).

* Internally, in our data structures, we use time_t to represent time and date information. That is some version of an integer measuring seconds since the epoch. Of course, translating between epoch and watch time is time zone dependent. But our “local time” for that purpose of unique value for translation is taken to be UTC.

* QDateTime (and their visual representations like the time chooser) are time zone aware and by default initialize to the default time zone of the computer. Those have methods to convert to/from time_t but since that is time zone dependent, we currently correct with our function gettimezoneoffset. Thanks to complications like daylight saving time, the offset is not constant over time but depends on time, so that function in principle takes a time_t argument but that is not universally used and thus problems occur. In addition, I have to use trail and error to figure out if in a specific situation I have to add or subtract the offset.

All this, at least to me, is quite confusing and a permanent source of problems.

So I would like to suggest a change of convention (and you can now tell me why this is a totally brain dead idea):

In order to make conversion between QDateTime and time_t simpler (actually trivial), let’s set all the Qt stuff to be in Qt::UTC. This would eliminate the need for time zone offsets for the matter of conversion entirely. We would only need the offsets when using things like current time (so we display local time although the UI element thinks it lives in UTC). We do this for example when planning a new dive which by default starts “an hour from now”.

My expectation is that this change would drastically reduce the need for conversions with time zone offsets and thus of errors.

Please tell me I am wrong.

Best
Robert

--
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                      Scientific Coordinator
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160621/f394d1d0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160621/f394d1d0/attachment.sig>