On quarta-feira, 22 de junho de 2016 22:47:33 PDT Robert Helling wrote:
> 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
> 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 = QDateTime::fromString(date + " " +
> time, "yyyy-M-d
> hh:m:s");
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
timestamp = QDateTime::fromString(date + ' ' + time + 'Z', Qt::ISODate);
Note: you need to ensure that the month, day and hour have leading zeroes.
Alternatively, parse date and time separately, then create the QDateTime from
the QDate and QTime objects.
In many places:
> QDateTime dt;
> + dt.setTimeSpec(Qt::UTC);
>[other code]
> - dt.setTime_t(gt.when - gettimezoneoffset(gt.when));
> + dt.setTime_t(gt.when);
Correct, but inefficient. Better would be:
QDateTime dt = QDateTime::fromTime_t(gt.when, Qt::UTC);
I've just realised that my recent changes in Qt 5.8 pessimises the default-
constructed QDateTime on 32-bit systems, compared to 5.7... gotta fix it.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
