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

[Robert Krawitz]

On 7/13/20 4:51 PM, Harald Barth wrote:
>> 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 ;-)

The time is not defined in either timezone or DST.  The issue is with the QDateTime parser.  If
there's no timezone specified, it treats the date as local time, including DST rules.  If the time
falls within that hour that doesn't exist, it's not a valid time by those rules.

My fix is essentially to treat it as local standard time by re-parsing as UTC (which does not have
DST), and then converting that back to local time after adding back the offset between standard time
and UTC.  That's essentially exactly what you're proposing there.

If there are more photos with the time _after_ 0300 local time, KPA has no way of knowing that the
camera was still set to standard time.

>> 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).
> 
> If you treat 2:20:00 as UTC-1 then it will indeed be 3:20:00 CEST so I think
> this is a very reasonable fix (oh, sorry, many words to say that).

Johannes's concern is that then photos taken at (according to the camera) 3:01:00 will then be
sorted before those taken at 2:20:00, because the one taken at 3:01:00 will have a valid timestamp.
That's true; I just don't see any clean way around it.