[digiKam-users] digiKam "date"s and times

[Jim Todt]

Thank you all for the prompt replies!

@Gilles:

"read the code" is unfortunately of limited value - many (like me) 
either can't or can't with any reasonable facility; reading a code 
snippet only reveals that snippet, not the whole picture; reading code 
can only show what the code does, not what it is _supposed_ to do; etc.  
To me, that last is key:  I would like to know what digiKam is 
supposed/designed/spec'd to do - because that is how I should arrange my 
workflow.

Agreed, this is a complex issue - all the more reason to know explicitly 
what is supposed to happen...

I looked at the bug but it doesn't seem to have any detail?  Neither 
exactly what might be implemented nor when?

@woenx:

I agree the EXIF Original date should be used.  Unfortunately in my 
tests so far digiKam ignores it. :(

@Maik:

Is there a (non-code :) ) description of how this ranking is supposed to 
happen?  And once this date (THE date) is determined, is it then 
supposed to be used everywhere for all functions within digiKam?  Or are 
other dates involved in different places/functions?

I don't understand the logic of your example.  In that scenario, the 
user hasn't "corrected" either their mistake nor the date.  The user has 
in fact _added_ another date and increased the problem.

Admittedly I don't have knowledge of all the bug reports or other 
scenarios - all the more reason I'd like to understand how digiKam is 
trying to resolve these issues.  If one believes that the user, at least 
from their perspective, "corrected" the date, then wouldn't a simpler, 
better approach be to confirm that with the user and then use this date 
for EXIF Original, as the user intended in the first place?

@all:

Would also appreciate your comments on the other questions:

View sorting uses filesystem dates?

Is there any plan/schedule for the EXIF Offset Timezone fields to be used?

Best Practices for dates, including UTC?

Thanks!