Created attachment 168348 [details] GPX Track *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY I took some photos today and used digikam geolocation editor to geotag them. This is something that I have done successfully many times. Two of the 21 images were not located using my default Interpolate setting of 00:05:00. They were correctly located when the time was increased to 00:06:00. STEPS TO REPRODUCE 1. Save a GPX file containing a track recorded at the same time as a number of photos were taken. 2. Use digikam geolocation editor to match the photos to the track to establish their coordinates. 3. OBSERVED RESULT Two images were not matched against the GPX track. EXPECTED RESULT All images matched. SOFTWARE/OS VERSIONS Windows: 11 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I always allow a margin of 5 minutes for interpolating images in case the Garmin eTrex 22x loses signal, as can happen in inclement weather. digikam shows the time that the two photos were taken was 10th Apr 2024 @ 11:45. The track shows 5 points during that minute (11:45).
The photos are too big to upload here. digikam metadata shows that one was taken at 11:45:29, the other at 11:45:37.
The problem is clear and easy to fix. @Gilles, Now that we are at Qt-6.7.0 with the Windows MSVC version, do we want to go back to a local date/time in digiKam or do we want to keep UTC as the timespec? One would probably be the speed of date calculations, we can easily test this with a change in digikam_globals.cpp without patching the entire code. The question is also, if we were to support time zones in the future, would UTC be better as a timespec? Maik
Qt 6.7.0 in VCPKG ? As i can see it's always 6.6.1. There is a PR, but not yet merged : https://github.com/microsoft/vcpkg/pull/37923 AppImage and MacOS uses 5.15.13. Gilles
Ah yes, I hadn't even thought about this dependency at the moment. Maik
@Steve, After looking at the code it doesn't seem to have anything to do with the UTC timespec we are currently using. Can you send me the two images by email.
I looked at the GPX data, you are in UTC time, +1 hour daylight saving time. I think you didn't set your camera to daylight saving time. Maik
>Now that we are at Qt-6.7.0 with the Windows MSVC version, do we want to go back to a local date/time in digiKam or do we want to keep >UTC as the timespec? yes, when 6.7.0 will be available >One would probably be the speed of date calculations, we can easily test this with a change in digikam_globals.cpp without patching the >entire code. yes, a factorized method checking the QT version will help here. >The question is also, if we were to support time zones in the future, would UTC be better as a timespec? I think yes. a C++20 response is given here : https://www.modernescpp.com/index.php/calendar-and-time-zone-in-c-20-time-zones/ Gilles
There is no problem in digiKam, I tested it with my test GPX route. For your images with 11:45:29 and 11:45:37, only a GPS time around 12:45:xx comes into question where the images correlated correctly. So you have to set your time zone to -01:00 in the digiKam correlation settings. We might have to make a checkbox for daylight saving time or calculate it automatically. Maik
(In reply to Maik Qualmann from comment #6) > I looked at the GPX data, you are in UTC time, +1 hour daylight saving time. > I think you didn't set your camera to daylight saving time. > > Maik That's probably true. Sorry to have bothered you. Steve