Re: [PATCH] Time zones (again)

Dirk, > Am 01.07.2016 um 17:30 schrieb Thiago Macieira : > > On sexta-feira, 1 de julho de 2016 11:04:32 PDT Robert Helling wrote: >> Hi, >> >>> Am 23.06.2016 um 06:21 schrieb Robert C. Helling >>> : >>> >>> Thanks for those comments. Will

Re: [PATCH] Time zones (again)

On sexta-feira, 1 de julho de 2016 11:04:32 PDT Robert Helling wrote: > Hi, > > > Am 23.06.2016 um 06:21 schrieb Robert C. Helling > > : > > > > Thanks for those comments. Will send an updated patch. > > here is the updated patch. Everything looks right, thanks

[PATCH] Time zones (again)

Hi,Am 23.06.2016 um 06:21 schrieb Robert C. Helling :Thanks for those comments. Will send an updated patch. here is the updated patch.From 01eb7dc4e15750a8f8b36f54f8aaadc5ee1a49b2 Mon Sep 17 00:00:00 2001 From: "Robert C. Helling" Date: Wed, 22 Jun

Re: [PATCH] Re: Time zones (again)

Hi, > Am 23.06.2016 um 04:17 schrieb Thiago Macieira : > > The assignment on that second line erases any settings from the previous line. > > If you want to parse *as* GMT, the only way to do it is using ISO format and > appending a "Z" to the target date. Something like >

Re: [PATCH] Re: Time zones (again)

thinking about > time zones again) but maybe I did not cover everything. More testing might > be advised. But looking at the code leaves me quite confident about it. > + timestamp.setTimeSpec(Qt::UTC); > + timestamp = QDate

Re: [PATCH] Re: Time zones (again)

On Wed, Jun 22, 2016 at 4:20 PM, Dirk Hohndel wrote: > > OK, this has gone wrong so many times... Linus, Thiago, would you take a > look at this and give an ACK if you agree that this is reasonable to take? The patch looks good to me. The only case that isn't obvious is the use

Re: [PATCH] Re: Time zones (again)

in particular with the planner (there it indeed fixes a bug reported > in the user forum which got me started in the first place thinking about time > zones again) but maybe I did not cover everything. More testing might be > advised. But looking at the code leaves me quite confident

Re: Time zones (again)

On terça-feira, 21 de junho de 2016 14:34:38 PDT Thiago Macieira wrote: > Anyway, Qt API updated for 5.8: > https://codereview.qt-project.org/163231 It has just passed CI testing and is confirmed now for 5.8. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software

Re: [PATCH] Re: Time zones (again)

with the planner (there it indeed fixes a bug reported > in the user forum which got me started in the first place thinking about time > zones again) but maybe I did not cover everything. More testing might be > advised. But looking at the code leaves me quite confident about it. > > Bes

[PATCH] Re: Time zones (again)

orks, then that sounds like a good idea. > > Linus Hi, here is a patch which implements (I hope) what I promised. I did some quick checks in particular with the planner (there it indeed fixes a bug reported in the user forum which got me started in the first place thinking about

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

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: 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