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

[Martin Höller]

Am 22. Sep. 2020 schrieb Robert Krawitz:

> On 9/22/20 3:56 AM, Martin Höller wrote:
[...]
> > If times are stored in UTC we could consider not saving it as a string
> > representation that would have to be parsed (e.g. "2012-08-16T12:01:09")
> > but as (milli)seconds since epoch (e.g. "1345118469"). Parsing a simple
> > number is much faster than parsing a date-string.
> > 
> > We did that in project an thus saved quite a huge amount of parsing time
> > on each load (we had several 100 millions of timestamps).  
> 
> It's remarkable how long it takes to interpret even milliseconds since epoch if UTC isn't specified.
>  The problem's not the parsing, it's all the corner cases and such with interpreting dates and
> times.  This based on measurement.

Well, my experience was with Java and the dates comming from a PostgreSQL
DB. So there might be big differences to C++/Text-Files.

> We've had a general principle that we want the index.xml file to be human-readable.  This would
> break that.

Well, I really like human-readable XML. However, if it effects
performance too much, my opinion would be to make it less readable is
tolarable. And it's not that it's unreadable then...

> My opinion: the database should store all dates in UTC, all the time.

Fully ACK.

> Then there's no ambiguity.
> It would solve the current problem, but we can't do this until we rev the database version.

As far as I understand we currently have no explicit timezone for the DB,
but implicitly the systems default TZ, right? So maybe just adding some
DB default TZ which would be used only when present would help?

> When someone selects images by date, of course, they expect to select it
> based on either local time or "time when the shot was taken", and we do
> a conversion then just for filtering.

That's right. But as long as we have no TZ per image, we could just
convert the input to the TZ of the images and not convert all images to
system/local TZ. That would be quite cheap.

[...]
> > While we are at it: it would probably be nice to have the opportunity
> > so show photo-times as "local time" or as "time taken". You know i
> > looks strange, when you see some midnight party photo and KPA says it
> > was taken at 15:07:21 because you are in a different timezone when
> > looking at the photo.  
> 
> Well, legacy photos won't have a timezone, so we don't even know how to
> interpret "time taken".

They have one, just not an explicit one but implicitly the system default
TZ.

- martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20200923/b325fb34/attachment.sig>