[KPhotoAlbum] Fw: Fwd: [Qt bugreports] Updates for QTBUG-75585: Massive performance regression in QML Date object

[Tobias Leupold]

So I finally looked at the code ;-)

In DB/ImageDate/ImageInfo.cpp:79, we see how we format our dates, in
QString ImageDate::toString(bool withTime) const

Converting the timezone-less dates is trivial. e. g. we have some date

    const QLatin1String xmlDate("2012-08-16T12:01:09");

We currently parse it likle that:

    const QDateTime originalDate =
        QDateTime(QDate::fromString(xmlDate.left(10), Qt::ISODate),
                  QTime::fromString(xmlDate.mid(11), Qt::ISODate));

Getting it into UTC is nothing more than:

    const QDateTime utcDate = originalDate.toUTC();

We format the date like this:

    date.toString(QString::fromLatin1("d. MMM yyyy hh:mm:ss"));

(by the way, shouldn't we use tr() or KDEish tr stuff here so that the
formatting could be localized?!)

Which leads to:

    "16. Aug. 2012 12:01:09" for formattedOriginal
    "16. Aug. 2012 10:01:09" for formattedUTC

The only thing we would have to do is to use QDateTime::toLocalTime:

    date.toLocalTime().toString(QStringLiteral("d. MMM yyyy hh:mm:ss"));

Which then also formats the UTC time to:

    "16. Aug. 2012 12:01:09"

So if we then store the UTC date in the database ("2012-08-16T10:01:09Z"), our
parser would (caused by the "T") interpret it as local time:

    QDateTime(2012-08-16 10:01:09.000 CEST Qt::LocalTime)

Thus, we have to use the current "without T" version, which calls

    QDateTime::fromString(xmlDate, Qt::ISODate);

Which is then yields the correct one:

    QDateTime(2012-08-16 10:01:09.000 UTC Qt::UTC)

So, summarizing:

Converting all dates to UTC should be no problem. We only would have to insert
a "toLocalTime()" call before outputting it. When searching, we simply convert
the date input to UTC and search against the UTC dates. Everything fine, isn't
it?

After the update, older versions of KPA will read the UTC dates as local ones.
This will lead to UTC dates being displayed. But, as far as I can see, there's
no way we can prevent this, as we simply didn't check for a timezone being
present in the database. Looks like this is the price we would have to pay.

> Yes.  But that's still an important case.

Maybe it is. I would do it like we did with the last breaking change when we
kicked out the localized category names. We create a backup of the database
before converting the dates and inform the user that we now use UTC in the
database and that there's no way back, but we did a backup which can be
restored if KPA is downgraded again.

> If the timestamps have
> been treated as local timezone but we switch to UTC, what do we do with the
> EXIF dates?  Treat them as UTC or treat them as local time? At least until
> someone has a camera that stores timezone in its EXIF data, we can probably
> just get away with treating everything as UTC (including search by date, or
> even time if we supported it) and done with.  But as soon as someone wants
> to read photos from a camera that stores timezone, what do we do?

I think this is quite simple: Date has a timezone --> we know the timezone,
respect it and convert from that to UTC. Date has no timezone --> we assume
that the date is in local timezone and convert to UTC. I see no problem here
...

> Converting to UTC in the database makes sense, but then we have the
> problems of how to interpret times on older photos,

Same thing: The dates have always been set for the local timezone, so we
assume them to be in local timezone and convert from there to UTC.

> and how to do searches. Doing searches based on UTC date won't work very
> well. If I want to
> search for photos taken on a given date at an event that spanned afternoon
> and evening (I'm based in US/Eastern), the search would be cut off at 7 or
> 8 PM (depending upon time of year).

If we convert the search term to UTC and match against the UTC picture dates,
there will be no problem, will it? It's the very same as matching a local time
against the picture's date in local time, isn't it? Maybe, I'm wrong here ...

Of course, we don't speak yet about a per-image timezone. Still, every date is
supposed to be local timezone, we only use UTC internally.

> We need to get those details right.

For sure.

> But once there's a camera that stores timezone, it gets difficult, fast.

I don't think so! If we have a timezone in the EXIF data, we know it and can
handle it peroperly. Still, the date is unambigous after being shifted to UTC,
no?!