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

[Tobias Leupold]

> A not quite correct solution that could be good enough is probably to
> convert everything to UTZ.

Still not having looked at the code (only thinking ;-) and supposing this 
will work without further problems:

Apart from all discussions, I think that the currently used format in the 
database is a problem. The date is not unambiguous. So if we have a photo 
at 2:30 on 2020-10-25, it's either before or after the time shifting. And 
there's no way to know that.

So I think we do have make it unambiguous. The most convenient and readable 
way would be to convert to UTC and append the respective timezone ("Z"). 
Another option would be to use the UNIX timestamp, but that would break 
downwards compatibility and would also not be human-readable.

I would do that via a db version bump and update function. Well, we could 
have the exact case mentioned above in some databases, but we can't change 
this. So we should simply always do the same and e. g. assume the photo has 
been taken during the "second" hour.

But we have another problem: If I travel somewhere far away and take a 
photo at 12:00, the displayed time will we converted to my local timezone 
and then be 4:00 or whatever. So we additionally do have to add a timezone 
to each photo that is used to calculate the displayed time. The display 
should of course contain a hint if the displayed timezone deviates from the 
local one.

I would add the local timezone of the user's machine by default for new 
photos, along with an option to set another timezone for each photo (of 
course only if the EXIF data does not contain a timezone. In this case, we 
should simply adopt it). Something like displayTimezone="..." or such.

This way, we get a consistent and unambiguous timestamp in the database and 
a convenient way to display the right time for each photo, even if it has 
been taken in a completely different timezone.

As a bonus, we apparently solve the performance issue by only using UTC for 
date and time comparisons internally.