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