[Digikam-users] Time Date based rename

[Mick Sulley]

Firstly many thanks Jean-François for the very comprehensive reply, I 
now have a better understanding of the issue, just need to decide how to 
manage it:)

My main camera is a Canon EOS 550D, which does not have a setting for 
time zone or daylight saving.

Now we are back on good old GMT I have tested again, and now the date is 
consistent in all fields and the file is renamed to the expected time 
and date.  So this means  that somehow DigiKam (or possibly my computer) 
decides that during BST the time on exif is GMT an renames the picture 
to an hour later to make it BST.  So if I always leave my camera set to 
GMT the pictures will show as the expected time when I import them into 
DigiKam.

Regards
Mick

On 26/10/13 18:53, Jean-François Rabasse wrote:
>
> On Fri, 25 Oct 2013, Mick Sulley wrote:
>
>> Hi Peter,
>>
>> Thanks for the reply.  Yes I see that as well, the exif data shows 
>> the same
>> time as the camera, the thing I don't understand is that DigiKam 
>> renames the
>> picture on import as one hour later than the exif date.  e.g. - from the
>> info panel on the right
>>
>>       File Properties
>>       PIC2013_1013_161516.JPG
>>       Date 13/10/2013 16:15:16
>> ...
>>       exif Photgraph Information
>>       Date and Time (original) 2013:10:13 15:15:15
>>       Date and Time (digitized) 2013:10:13 15:15:15
>
> Hi Mick,
>
> These datetime issues are often a nightmare and will go on being.
> This because of a major weakness in the Exif standard and unaccurate
> specifications on how to process time by application programs.
>
> The Exif standard has provided fields for datetime stamps, but has
> forgotten the time reference, too bad:-(
> The standard fields have a fixed length of 19 ascii characters and
> can accomodate things like "2013:10:13 15:15:15", nothing more.
>
> Some camera manufacturers implement extra information, the time
> zone and the daylight savings flags, but this is not standard Exif
> and has to be stored in the Maker notes part of the Exif section.
> Application programs may, or not, decode and use.
>
> Note that this information is only informational and it's up to the
> user to ensure consistency in the camera setup. It doesn't work like
> a computer where you can set the hardware clock to UTC, then
> specify you living time zone and daylight savings, and the operating
> system will use all that and rebuild a valid local time.
>
> In a camera, the datetime field is supposed to be ... a date, and
> application programs are allowed to assume it's a local time.
> The problem is this is not correctly defined. E.g. when referencing
> to the XMP standard (XMP is expected to handle valid dates in ISO
> 8601 format, i.e. things like "2013:10:13 15:15:15+01:00" (this in
> your case, time zone Greenwich, daylight savings active).
> but the standard says :
>  « If no time zone is contained in the EXIF, convert to XMP assuming
>    a local time. »
>
> A local time ! Which local time ? The local time at the moment the
> camera took the picture, or the local time on the computer reading
> the image ? No one knowns. And software do more or less what they
> want. This is why you get different results with exiftool or with
> Digikam which uses the exiv2 library.
> Exiftool may decide to use the Exif timestamp as a neutral template
> and Digikam/libexiv1 may decide to adjust from your computer daylight
> savings, thus giving + 1 hour.
> (Try again tomorrow :-)
>
> Also, neither exiftool nor libexiv2 produces correct dates when encoding
> XMP sidecar files, the fractional part of seconds is added but the time
> zone offset is missing.
>
> This is a real problem when geotagging images from a GPS tracks log,
> where the UTC time of the image is required for correlation.
> And correlation programs provide a time shift option to let the user
> adjust when the results are silly.
> Similar problems for people that travel, take a photo before boarding
> a plane and look at the photo once back home, maybe a couple of hours
> "before" :)
>
> Anyway, the best way is probably to maintain cameras datetime to the
> user localtime, i.e. what's shown by your wrist watch.
> I totaly agree with Peter saying « I manually adjust the camera time
> twice a year ».
> I do the same, adjust the time AND toggle the daylight savings mode,
> this to keep the information for future (i.e. programs able to
> process a correct time from all the information).
>
> An alternative is to have a camera with a GPS device, giving a valid
> UTC timestamp at the moment the picture is shot, be you at home or
> in Japan or Australia.
>
> Cheers,
> Jean-François
>
>
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20131028/f309018b/attachment.html>