[Digikam-users] Time Date based rename

[Jean-François Rabasse]

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