Re: Time zones (again)

On terça-feira, 21 de junho de 2016 22:43:04 PDT Robert Helling wrote: > 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 >

Re: Time zones (again)

On terça-feira, 21 de junho de 2016 13:20:25 PDT Linus Torvalds wrote: > The problems for the kernel are all the embedded timeval pointers in > user space structures that get accessed through ioctl's (or things > like poll/select timeouts), or all the filesystems that have odd > timestamp limits

Re: Time zones (again)

On Tue, Jun 21, 2016 at 1:43 PM, Robert Helling wrote: > > I didn’t mean init of subsurface. I meant init of QDateTime. Yes, if that works, then that sounds like a good idea. Linus ___ subsurface mailing list

Re: Time zones (again)

Hi, > Am 21.06.2016 um 17:18 schrieb Linus Torvalds : > > > On Jun 21, 2016 01:16, "Robert Helling" > wrote: > > > > What I propose is upon initialization setTimezoneSpec > > once with UTC then for conversion

Re: Time zones (again)

On Tue, Jun 21, 2016 at 12:44 PM, Thiago Macieira wrote: > > I don't see such functions yet in the latest git://git.kernel.org/pub/scm/ > linux/kernel/git/torvalds/linux.git. I could only find the regular > gettimeofday > in kernel/time/time.c and the compat version in

Re: Time zones (again)

On terça-feira, 21 de junho de 2016 12:03:41 PDT Linus Torvalds wrote: > On Tue, Jun 21, 2016 at 11:22 AM, Thiago Macieira wrote: > >>fromTime_t(qint64, const QTimeZone); > > > > I can add that, but I can't add a qint64 toTime_t(), as you can't overload > > on return

[PATCH 2/2] Initial Suunto EON Steel CCR support

From: Linus Torvalds Date: Mon, 20 Jun 2016 22:51:52 -0700 Subject: [PATCH 2/2] Initial Suunto EON Steel CCR support This does the basic divemode and setpoint parsing for the EON Steel, and gets the CCR download right in the big picture. The cylinder information

[PATCH 1/2] Suunto EON Steel: add descriptor debugging output

From: Linus Torvalds Date: Mon, 20 Jun 2016 22:04:27 -0700 Subject: [PATCH 1/2] Suunto EON Steel: add descriptor debugging output .. every time I look for a new feature I add debug code to print out all the descriptors. So let's just do it once and for all.

[PATCH 0/2] Some initial Suunto EON Steel CCR patches

The first patch is something I should have sent in long ago, rather than always do ad-hoc every single time I want to check new fields from the dive computer: add debug support for showing all the dive descriptors. That patch has no semantic difference, but it means that the download logs

Re: Time zones (again)

On Tue, Jun 21, 2016 at 11:22 AM, Thiago Macieira wrote: >> >>fromTime_t(qint64, const QTimeZone); > > I can add that, but I can't add a qint64 toTime_t(), as you can't overload on > return value. So it would only be a half solution. Can you at least make sure that the

Re: Time zones (again)

On terça-feira, 21 de junho de 2016 10:26:50 PDT Linus Torvalds wrote: > On Tue, Jun 21, 2016 at 9:08 AM, Thiago Macieira wrote: > > That function is totally busted, as you've noticed. Not fixing is a > > discouragement, forcing people to find better alternatives. > > Quite

Re: Time zones (again)

On Tue, Jun 21, 2016 at 9:08 AM, Thiago Macieira wrote: > > That function is totally busted, as you've noticed. Not fixing is a > discouragement, forcing people to find better alternatives. Quite frankly, not fixing it is just stupid. It doesn't force people to find better

Re: Time zones (again)

On terça-feira, 21 de junho de 2016 01:09:16 PDT Linus Torvalds wrote: > The "fromTime_t()" function was an example of such a case : ostensibly the > right thing to use (converts from a time_t, which was exactly what we > wanted) but doesn't take a timezone input. We didn't update it with a

Re: Time zones (again)

On Jun 21, 2016 01:16, "Robert Helling" wrote: > > What I propose is upon initialization setTimezoneSpec > once with UTC then for conversion functions there is no > further need to explicitly state time zone specifications I don't think we can do that. There are several

Re: two kirigami issues

On Sunday 19 June 2016, Dirk Hohndel wrote: > Hi Marco, > > The latest Kirigami causes two problems for Subsurface-mobile > ha! i know what it is: the ScrollablePage component only finds the flickable it's supposed to scroll if its either its only or last child, due to how default qml

Re: two kirigami issues

-- Sent from my phone On June 21, 2016 2:23:40 AM PDT, Marco Martin wrote: >On Sunday 19 June 2016, Dirk Hohndel wrote: >> Hi Marco, >> >> The latest Kirigami causes two problems for Subsurface-mobile > >Hi Dirk, >are those 2 problems on the current master branch? Yes >

Re: two kirigami issues

On Sunday 19 June 2016, Dirk Hohndel wrote: > Hi Marco, > > The latest Kirigami causes two problems for Subsurface-mobile Hi Dirk, are those 2 problems on the current master branch? > 1) in portrait mode the top entry of the dive list is half-hidden by the > application header; we used to have

Re: Time zones (again)

Benjamin, > On 21.06.2016, at 10:10, Benjamin wrote: > > It sounds like a good idea, but how would it affect dives which are currently > in logs? Would there then need to be a layer to check dates on load/save and > correct them to UTC? I can't think of other possible

Re: Time zones (again)

It sounds like a good idea, but how would it affect dives which are currently in logs? Would there then need to be a layer to check dates on load/save and correct them to UTC? I can't think of other possible problem areas, but maybe somebody else can? Benjamin

Re: Time zones (again)

On Jun 21, 2016 00:57, "Robert Helling" wrote: > > 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. Yes. I did that to some of the time handling functions already, and removed some of the odd

Time zones (again)

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