add dive implementation pushed

[Dirk Hohndel]

On Fri, 2013-09-20 at 09:04 -0500, Thiago Macieira wrote:
> On sexta-feira, 20 de setembro de 2013 08:56:25, Dirk Hohndel wrote:
> > The time zone thing puzzles me. I thought I did that right in the code (not
> > for add dive but for the planner itself) but the time is off by an hour...
> > And googling really doesn't help... People mostly saying "it's broken in
> > Qt4".
> 
> QTimeZone was submitted for Qt 5 this Tuesday. I did my initial review of it 
> yesterday and, though the API looks good, the implementation needed a few 
> updates. I haven't checked yet whether the contributor has updated it today -- 
> and today is feature freeze for 5.2.
> 
> Without QTimeZone and the QDateTime updates already in for 5.2, QDateTime only 
> officially supports "local time" and "universal time", just like POSIX. However, 
> since 4.4, the methods setUtcOffset() and utcOffset() exist. I just don't know 
> if they work and whether QDateTimeEdit & friends work with them.
> 
> I recommend we work with the dates like Git does:
> - let the user input them as local time
> - use QDateTime to convert to universal time + offset
> - store as universal time + offset

No - that doesn't work in the context of a divelog. Divecomputers
universally use localtime. Some claim to have TZ offsets (like the
Uemis), but that's just "FYI". All time stamps are always local time.

So when we add or plan a dive, we need to be able to get the current
time in local time - expressed as seconds since Epoch. Here's what I
think would do it:

diveplan.when = (t.msec() + QDateTime::currentMSecsSinceEpoch()) / 1000
- Qt::OffsetFromUTC * 3600;

where t is the QTime widget used to enter the time offset from 'now'.

/D