[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]

Am Montag, 13. Juli 2020, 22:51:42 CEST schrieb Harald Barth:
> > 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.
> 
> Invalid is a bit harsh because the time in question is probably not
> specified to be DST or not. Here where I am, up to 01:59:59 we have
> for examle CET as a localtime until the switch is made. The minute
> after we have 03:00:00 CEST as localtime. If one now encounters a time
> that is 02:xx:yy on that date it is not invalid but it is just not
> localtime. In this example it's proably UTC-1 (if you forget to adjust
> your clock in the middle of the night it will run on UTC-1 in the
> morning. The sun dial in my garden runs approximately UTC-1 all year
> long as I don't adjust it (well I could, it has a center screw ;-)

Well, I did paraphrase a number of mails and this got lost ;-)

Yes, you are correct - the core problem is that exif (prior to version 2.31) 
has no notion of timezones. KPhotoAlbum thus treats any time as local time. 
Thus we can end up with the mentioned problems in two ways:
(1) an image was taken during the leap hour, but the camera time was not yet 
adjusted to DST
(2) an image was taken in some other timezone, but when treating it as local 
time it appears to be taken during leap hour.

While I'm at it, I copy-paste the "correct" approach from a previous mail of 
mine:
So that leaves the even more intrusive but correct approach: include timezone 
information in our timestamps. This is obviously not a quick fix and would 
need some preparation and careful planning, not to mention major changes in 
the way we deal with timestamps in the UI.

Cheers,
  Johannes

P.S.: I really should have paid more attention to not leaving out the list :)