https://bugs.kde.org/show_bug.cgi?id=484719
--- Comment #19 from mahikeulbody <mcfaro...@gmail.com> --- After to decide that a QuickTime date of a given video is UTC (which is not easy, I agree), Digikam uses the local time of the PC to calculate the "local" time of the video. This "local" time is incorrect if the video was been taken in a foreign country (with a time zone different from that of the PC). This incorrect "local" time impacts 1) the sorting by date 2) the renaming with format such as [date:yyyy-MM-dd_hh'h'mm-ss]. The more logical way for the user to manage this "travel" use case is the following : When he come back to his country, he adjusts the dates of his travel videos he know they have a true UTC QuickTime date (i.e. from smartphones) in order to set them to the right local time (offset = QTdate - timezone&dst of the foreign country). But this way, he cannot rename these videos with a format such as [date:yyyy-MM-dd_hh'h'mm-ss] because Digikam is not aware the date are local time now. So I workaround the problem adjusting the date of these videos with an offset = TZ of the foreign country – TZ of my PC. This way I can then to rename the videos with a format [date:yyyy-MM-dd_hh'h'mm-ss]. Sorting by name (not by date !) allow me to displays the photos and videos of a travel with the right chronology. I think the best solution is the first one (adjust to local time) and add an option to the rename function to notify Digikam not to adjust Timestamp Updated with the local time of the PC. This way I can also sort/search by date consistently within a travel sequence. -- You are receiving this mail because: You are watching all bug changes.
