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

[Johannes Zarl-Zierl]

Hi,


Am Montag, 21. September 2020, 14:40:02 CEST schrieb Tobias Leupold:
> Am Montag, 21. September 2020, 14:23:54 CEST schrieb Robert Krawitz:
> > Here's the answer I got.
> 
> Well, if using only UTC dates makes it better, we could think about doing
> that. At the moment, we don't even include a timezone information in the XML
> file, e. g. we have startDate="2012-08-16T12:01:09".

This kind of brings me back to the discussion we had in June/July about 
Daylight saving time problems[1]. While we got away with a quick fix that 
time, this tips the balance more into the "we need to fix this" direction.

[1] https://mail.kdab.com/pipermail/kphotoalbum/2020-June/006615.html


>From both discussions we get two requirements:
My conclusion to the referenced discussion was that a proper solution would be 
to add timezone info to the database. A not quite correct solution that could 
be good enough is probably to convert everything to UTZ.
For the current issue, we would need UTZ data only in the database.

So simple solution would be to convert to UTZ and be done with it.

I still think that the proper solution to the problem would be to add real 
timezone support (in the future, more and more cameras will come with EXIF 
2.31) and having proper timezone info will allow us to retain local time for 
display.

Given that a generic solution in QDateTime seems unlikely, why not implement a 
wrapper that does the caching? This would not be all that different from our 
approach with DB::FileName. Just don't call it QuickTime ;-)

Cheers,
  Johannes