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

Hi!

Am 22. Sep. 2020 schrieb Andreas Schleth:

> > 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).  
> 
> Hi,
> 
> just my 2 cents: I have old images scanned with dates like "18. Sept.
> 1926" - This is far before the start of the Unix epoch (1.1.1970). And
> in only 18 years from now, the epoch ends. So, I suggest to forget all
> ideas to use or store any integer representation of the date.

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.

[...]
> As far as the rest of the discussion goes I wonder:
> 
> Is it really that important to have exactly the true time as a time
> stamp? For me the relative time between images is more important because
> that determines the sorting order.

You are right. But we still shouldn't loose the exact time. So IMHO there
is no advantage in looking at image-time the way you propose.

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

Regards,
- martin

_______________________________________________
KPhotoAlbum mailing list
[email protected]
https://mail.kdab.com/mailman/listinfo/kphotoalbum

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAl9q3T8ACgkQYJf22JPx7tn7kQCgtZzCYingRyje5x4J5E4/4p00
C+gAoNIFaWsw+zrZcLkKcBfmrz3ly1gC
=zeXl
-----END PGP SIGNATURE-----