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

[Tobias Leupold]

Thinking it through again, maybe there's actually no real benefit in having
UTC dates in the database.

Johannes is right, it will make thinks more complicated. But apart from that,
I think from an end-user's point of view, there is really no advantage: It's
interesting when the photo was taken. In the local time present at the very
moment where it was taken. It doesn't matter if the photo was taken in another
timezone. 12:00 is 12:00, and that's the thing we need to know. Also if one
moves to another timezone, 12:00 photo time is still 12:00.

Additionally, if the camera doesn't deliver a timezone, we have no chance to
know if the photo e. g. has been taken during the first or the second same
hour when a timeshift is done due to DST. So for this corner-case, UTC won't
help either.

After all, I meanwhile think we should leave the date and time as-is and
"only" solve the performance issue ;-)

> What I have in mind is creating a KPADateTime class that embeds (not
> inherits from) QDateTime.

Do we really need a new wrapper class? We already have DB::ImageDate, which
already wraps around QDateTime. It also already implements comparison
operators. Would it perhaps be possible to put the optimization/caching in
this class?