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

[Just Lettuce]

Hello all,

Been offline for a bit...   Thanks all for figuring this out!  
Confirming that my photos from more recent cameras (and years) that also 
lost dates were from the same issue.  I had not noticed that pattern.  I 
used to own a bar, and we closed by 02:00 and were supposed to have 
everyone out by 2:30 - so even if 2:30 didn't actually exist on those 
nights, it kind of did for us.  And of course I never reset the time on 
my camera when trying to get everyone out...

I can change times, and understand the sort issue might be a problem.  
Also wondering how things go in the future with time changes?  We 
actually had our last time change here in Yukon in the spring.  Time 
changes are done here.  It's not changing in the fall.  I think British 
Columbia is doing this also, but not California, etc.?  Could get 
complicated?   I guess 4.7.1 didn't check the date/time the same way?  I 
think I would like a way to switch off this validation and just accept 
exif date/time, though I realize there would be issues with this also.

That all said, I can change times - and/or use whatever other solution 
or change that might appear.

Thanks as always for the great work!
-n



On 7/13/20 2:16 PM, Robert Krawitz wrote:
> 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.
>