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

[Robert Krawitz]

On 9/23/20 1:42 AM, Tobias Leupold wrote:
>> Negative values are ok, so 1926 wouldn't be a a problem. And modern
>> implementations even work after 2038, so this would'nt be a problem
>> either.
> 
> You're right, but still, readability of the XML file has always been important
> for KPA. So I think we really should stick to the ISO 8601 dates.

+1

>>> As always, I would love to see the database format stable - especially
>>> when importing / exporting image sets via *.kim.
>>
>> That's an important point. But IMHO it need's not to be stable but
>> backward compatible. If we could just add information old implementations
>> could still work with it.
> 
> Please notice that any compatibility problem only can arise if you open your
> db with a new version of KPA so that it's updated and then downgrade KPA
> again.

Yes.  But that's still an important case.

The database schema includes more than the raw data definition.  It also encompasses the
interpretation of the data fields.  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?  Converting to UTC in the database makes sense, but then we have the problems of how to
interpret times on older photos, 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).

We need to get those details right.

> And in this case, if we dot it like I would propose it, the only inconvenience
> would be that the times may be displayed in UTC. I'm not sure about this
> though, I didn't look at the displaying code yet. Even older versions of KPA
> should correctly parse the newly added timezone.

Again, for the majority of cameras that don't currently store timezone in the EXIF, this might not
be a problem -- if the dates are consistently interpreted as UTC, just treat all dates as UTC,
period.  But once there's a camera that stores timezone, it gets difficult, fast.