[KPhotoAlbum] Fwd: (file)Re: Date disappearing from database for certain photos in 5.4.2 and 6.2.1 (though not a problem in 4.7.1)

[Johannes Zarl-Zierl]

[re-adding the ML to the recipient list because we lost it some time ago...]

Summary for the ML:
Robert found out that the issue is with the timestamps itself and not a 
problem with KPhotoAlbum as such. When switching from "normal" time to 
Daylight Saving Time (DST), the time jumps from 1:59:59 to 3:00:00. Image 
timestamps that fall into this leap hour are invalid.
Robert then devised a workaround that would detect an invalid image date and 
convert it to a correct timestamp (2:20 would become 3:20 in this example).


Am Montag, 13. Juli 2020, 02:28:35 CEST schrieb Robert Krawitz:
> > As a user I do prefer a clearly invalid date over a silently "corrupted"
> > data. How about we just detect the situation and alert the user?
> 
> There's already "Display images with invalid dates...", which covers this
> situation (one of the options being images with a valid date but invalid
> timestamp -- maybe this had come up before?).

I tried this yesterday and I couldn't make anything of the output. After 
apparently reading exif data from all image files in my database, a list of 
changes(?) was displayed. It was not obvious to me what the supposed problems 
were with the displayed image dates.

As it is, I think removing this dialog altogether would be an improvement.

> What could the user do with the alert?  They'd have to manually set the time
> on possibly a lot of images (if someone's out shooting at that time of
> night, they might be shooting a lot -- or their clock may simply be way
> off).  If I shot 100 frames during that hour, I'd *really* hate to get an
> alert for each photo, and then have to reset the time on each.

Well, it wouldn't have to be one alert per image. You could alert at the end 
with a list.

Thinking about this a little more, maybe another option presents itself here:
We could give the user a choice to (a) ignore the image timestamp (b) set a 
fuzzy time (c) adjust the timestamp for DST on the image (d) adjust the 
timestamp for DST on the image and all other images (or just on the same 
day?).

Note: that's all options I could come up with - maybe presenting all options 
to the user is actually worse than a sensible subset.

My favorite option as a user would probably be (d), followed by (b).

> Setting the date in the database this way isn't really "corrupt", either. 
> It's simply a limitation of how the time is expressed in the camera. 
> Arguably the timestamps on the files shot after 3 AM are the ones that are
> wrong -- they should be DST-adjusted.

"Corruption" may be a strong word here, but in essence it *is* timestamp 
corruption if a series of images end up being sorted incorrectly.


Cheers,
  Johannes