<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 21.06.2016 um 17:18 schrieb Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org" class="">torvalds@linux-foundation.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""><br class="">
On Jun 21, 2016 01:16, "Robert Helling" <<a href="mailto:helling@atdotde.de" class="">helling@atdotde.de</a>> wrote:<br class="">
><br class="">
> What I propose is upon initialization setTimezoneSpec<br class="">
> once with UTC then for conversion functions there is no<br class="">
> further need to explicitly state time zone specifications</p><p dir="ltr" class="">I don't think we can do that.</p><p dir="ltr" class="">There are several cases where we do want local time, notably when we ask the system "what time is it now". Then we want the hours, minutes and seconds as they are locally, not as they are in UTC.</p><div class=""><br class=""></div></div></blockquote>100% ACK<br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">We then convert the end result into "what would that be in UTC", but to initially get the current time field we need local time conversion.</p><div class=""><br class=""></div></div></blockquote>ACK.<br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">Globally setting "we want UTC" might also screw up other things - I could imagine things like file open dialogs showing odd times etc</p><div class=""><br class=""></div></div></blockquote>I think I was really talking about the Qt data structure as those are related to the UI. For example, to set the start time of a dive, we have a QTimeEdit widget. There the user enters something like „5:00pm“ or „17:00“. The widget delivers the result as a Time and eventually (together with a QDateEdit) we obtain a QDateTime. The user never saw any time zone information, just 5pm. But internally, this value goes into dive->when which is a time_t and so far, as far as I can tell, our rule for conversion of a dive starting at 5pm (local time of the dive) into time_t was: Since we don’t want to know about time zones, for the purpose of the conversion, the time_t value for us is „number of seconds between 1 Jan 1970 0:00 UTC and whatever day 5pm UTC“.</div><div><br class=""></div><div>QDateTime is time zone aware and by default it lives in the default system time zone. So what we do is compute the number of seconds between 1 Jan 1970 0:00 UTC and some date 5pm system time zone and the subtract gettimezoneoffset() which is the difference between some date 5pm UTC and 5pm system time zone.</div><div><br class=""></div><div>All I am proposing is to tell the QDateTime (that corresponds to the QTimeEdit) right after its creation (in an OO sense) that it should pretend to be in UTC. Then we would not need to do the gettimezoneoffset() gymnastics. </div><div><br class=""></div><div>We would of course then have to do it, as you and I said, when the current time comes into play. But as far as I can see these places are much fewer.</div><div><br class=""></div><div>I am not proposing to set the total subsurface time zone (what I called system time zone) to UTC. I just want it for QDateTime objects that are related to displaying things like „5pm“ to the user.<br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">But maybe I misunderstand what you were proposing. But I think the UTC thing needs to be done per operation, not set once at init time.</p><div class=""><br class=""></div></div></blockquote>I didn’t mean init of subsurface. I meant init of QDateTime.<br class=""></div><div><br class=""></div><div>Best</div><div>Robert</div><br class=""></div></body></html>