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

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

A floating point value would do however (like in the spreadsheets):
"(days since some epoch).(fraction of a day)". This makes date
comparison trivial. You loose a bit of precision if the images are a few
decades apart but who cares? This even works with negative values for
days before the epoch.

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.

Most internal camera clocks drift off the real time pretty fast and they
are not synced via NTP or GPS or such. So, even if the camera is set to
approximately the proper time, it will be off by a few minutes some days
later. How often do you check the clock on your cameras? My cameras
drift apart all the time, even if I take care to set them correctly,
let's say at the start of a holiday.

If I merge photo sets from different cameras (and my smartphone which
has the "best" time), the sorting order is always a bit out of sequence.

So the input data are inexact or dubious to start with, especially if
you deal with images taken by strangers. There may be exceptions (eg.
smartphones).

For my purpose, the time is just a convenient means for sorting and
selecting (on the fabulous date bar).

I think (maybe I'm wrong), the discussion started with some times
falling into the gap between regular and daylight saving time and thus
becoming "impossible" date/time values. Would it not be possible to just
do a local fix for this by assigning the nearest "legal" timestamp on
import and maybe add a token and a warning message? (as with videos that
are too short)

For me it is more important whether a picture was taken during local
daytime, in the morning or in the evening or night than having a
scientific exact UTC timestamp. If somebody really needs the timesstamp
she or he can always look at the exif data. In the end I rarely look at
the timestamp as TIME but mostly as a sorting tool. A date is different:
that might be a birthday or another important day.

As always, I would love to see the database format stable - especially
when importing / exporting image sets via *.kim. You should never assume
that all parties concerned run the same version of KPA.

And again: 1+ vote for a nifty time shifter tool to sync out of sync
sets of images :-) (this is off topic, I know).

Best regards, Andreas