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

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".

If this won't break downwards compatibility (I didn't look at the code yet),
we could convert all timestamps to UTC, supposing they are in local timezone.
Like startDate="2012-08-16T14:01:09Z" or such for the above example. This
could be done via a db version bump and update procedure and would only have
to be done once, processing all dates.

For newly added images, we simply do like so without a noticeable performance
impact, as the conversion only takes place once, when they are initially
added.

Actually, this is imo a shortcoming that should be fixed anyway, as the
currently used format isn't unambiguous and will deliver the wrong time if a
user e. g. moves to another timezone. Around midnight, it will even deliver
the wrong day ... also, we have a problem with DST, as once a year, the same
hour passes two times with no way to know when exactly the photo was taken
without knowing the timezone!