Bug 367611 - Time gap on renaming at download...
Summary: Time gap on renaming at download...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: AdvancedRename-Import (show other bugs)
Version: 5.1.0
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL: https://drive.google.com/drive/folder...
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-20 19:21 UTC by Camilo Bohórquez
Modified: 2016-11-25 06:48 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.4.0
Sentry Crash Report:


Attachments
Terminal Output DK5 rename on import not working (42.80 KB, text/plain)
2016-08-31 15:50 UTC, Mick Sulley
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Camilo Bohórquez 2016-08-20 19:21:41 UTC
When I set my system for UTC Hardware clock as YaST time settings suggest (See YaST screenshot), digiKam at importing process rename my pictures & videos with a time difference about my real time zone (See the digikam importing screenshot). The photograph properties show a real creation date from my camera, but digiKam show and rename my pictures in this case with the UTC time zone.

The problem only solves temporarily, when I uncheck the UTC hardware clock option in YaST. But I like mantain enabled this option and without this bug at impoort and renaming in digiKam.

Thanks in advance, for solve this problem.

Reproducible: Always
Comment 1 Camilo Bohórquez 2016-08-20 19:29:32 UTC
Correction: The time difference is, My Time Zone (UTC -05:00) minus 5 hours.
Comment 2 Mick Sulley 2016-08-28 20:07:39 UTC
I seem to have a similar problem DK5.1 on Mint 18
My rename command is PIC[date]{unique} 
When I import from my camera (Canon EOS550D) DigiKam adds 1 hour to create the file name.  If I then select the group of pictures and select Rename it renames them correctly. 
As a test - 
Just took a picture of my computer clock showing 21:15:42
The import has renamed it PIC20160826T221542.JPG
which is out by 1 hour (and a second, but I can live with that)
Looking at metadata I see
EXIF
Image Info - Date and Time    2016:08:26 21:15:41
Photo Info - Date and Time (digitized)    2016:08:26 21:15:41 (original) 2016:08:26 21:15:41
XMP
Create Date    2016-08-26T21:15:41
So everything says 21:15:41, but it renames to 22:15:42

Please let me know if you need more info.
Comment 3 Maik Qualmann 2016-08-28 20:28:19 UTC
DigiKam Import defaults uses the file creation date. For a exact date enable in camera setup the option: Use file metadata (makes connection slower).

Maik
Comment 4 Mick Sulley 2016-08-31 15:50:56 UTC
Created attachment 100866 [details]
Terminal Output DK5 rename on import not working
Comment 5 Mick Sulley 2016-08-31 15:53:23 UTC
Yes the time seems to be a camera issue.  However in testing I now see that rename on import is not working in DK5.  I tried in DK4 and that seems fine.  I started DK5 in a terminal and have uploaded the output.  Pleas let me know if I can provide any other info.
Thanks
Mick
Comment 6 Maik Qualmann 2016-08-31 19:53:24 UTC
Renaming in Import works here. Your rename command is PIC[date]{unique}? What see you in the icon view as preview file name?

Maik
Comment 7 Mick Sulley 2016-08-31 21:06:55 UTC
For the picture highlighted I see the updated name as expected, but for all the others I see the original IMG_1234 name.  Just tested again, took two pics which gives me 4 to import, 2 JPG and 2 CR2.  I highlighted one which then showed the new name, imported and that picture was renamed correctly, the other 3 were not renamed.
Repeated it again, this time I highlighted all the pictures in the import screen and they were all renamed.  At least that gives me a workaround for the problem.
Comment 8 Maik Qualmann 2016-09-01 06:11:01 UTC
This is the normal behavior. Only the selected or if no item is selected, the renamed file name is displayed. Otherwise the preview with numbered items would not be correct for selected.

Maik
Comment 9 caulier.gilles 2016-11-25 06:48:06 UTC
Following previous comments, I considerate this file are solved now.
Don't hesitate to re-open if necessary.

Gilles Caulier