DateTimeDigitized cannot be time shifted

[vladak]

My phone got crazy a bit and reset its date to 31st Dec 1999 and I made couple of photos with this invalid setting before I realized it. As a first thing I tried time shift using:

$ exiftool -DateTimeOriginal+='12:4:10 0:0:0' bad-date-directory
    1 directories scanned
   84 image files updated

so that worked for the 'Date Time Original' field (I am viewing the EXIF metadata using Preview on OS X).

I still needed to change the 'Date Time Digitized' field as well. I tried this:

$ exiftool  -DateTimeDigitized+='12:04:09 0:0:0' bad-date-directory
    1 directories scanned
    0 image files updated
   84 image files unchanged

which did not work.

Eventually I resorted to this (after reading documentation on the web):

$ exiftool  -AllDates+='12:04:09 0:0:0' spatny\ datum
    1 directories scanned
   84 image files updated

which fixed both data fields.

However, I still wonder whether the behavior (with shift of DateTimeDigitized not having any effect) is correct. I tried to change a single letter in the 'DateTimeDigitized' parameter and exiftool reported "tag does not exist" so it is certainly interpreting it but it does not have any effect.

[BogdanH]

Hi vladak,

ExifTool uses CreateDate tag name instead of DateTimeDigitized.

Bogdan

[vladak]

Okay, should not the DateTimeDigitized be an alias to CreateDate then ?

[Phil Harvey]

DateTimeDigitized refers to an XMP tag.

Here is the list of all ExifTool aliases.

- Phil

[xor42]

Hi vladak, ExifTool uses CreateDate tag name instead of DateTimeDigitized.  Bogdan

Aliases are typically used in two different ways:

• As an "Also Known As" or a.k.a. so the original word or the alias can be used interchangeably.
• As an exclusive replacement.  That is, it supersedes and disables use of the original word.

There is little point or cases for option #2.  Option #1 is simple, clear, and effective.

The Operational Bug:
Unfortunately, ExifTool seems to have a bug in that neither case is implemented.  It accepts the object "DateTimeDigitized" as a valid token, acts upon it as if were doing something, and invariably returns saying nothing was updated.  Using "CreateDate", however, works correctly, albeit confusedly, and updates the "DateTimeDigitized" field.  Jeez.

Needed Fix:
Hey, Phil.  I find it totally confusing to have to use the token "CreateDate" to change a field with the different name of "DateTimeDigitized".  What's the point of that?  This is not a complicated situation. The file headers have field names and value pairs within them.  The syntax should allow ANY header name to be modified as along as the operator specifies the field name correctly.  Very simple and effective.  You can, should you so prefer, create an optional auxiliary table of aliases that are NOT exclusive.  That is, the true native name will always work and so will any defined aliases. That's how I always wrote all my programs, tools, parses, and translators.

By NOT allowing native field names to be used, it is an unnecessary nightmare to find out the required exclusive-use "alias" when the original field name would have sufficed very nicely.  It makes a simple and great tool a nerdy back office booby trap for masochists

The Plot Sours:
Soon after I verified the soundness of my pearls in this missive, I found that even the so-called "Alias" of "CreateDate" is not documented as an independent field in several "Alias" lists I found even though it can be used to change the value of another field, "DateTimeDigitized".   Perhaps there is updated documentation that is readable somewhere I didn't look yet.  And here I thought it was confusing, before.  Ha!  So, it turns out that NEITHER DateTimeDigitized" and its so-called "Alias" of "CreateDate" are listed as independently actionable objects.  Only "CreateDate" is mentioned in passing as one of the three dates modified using the "AllDates" token/object.  That is further problematic since there are more than 3 time/date fields found in most EXIF headers, especially when OEM variants interject their puffed up body parts.

Phil, I applaud the depth and power of ExifTool but also have to give an elbow to the ribs for some of the syntactic oversights that can cripple its use.   As TK Anthony said,
"I know all too well how that goes" :-)

What say you, Phil?

[Phil Harvey]

Interesting post.  Did happen to see the Tag Names documentation?

ExifTool could use a consistent naming convention if there was consistency between the different types of metadata.  Unfortunately though, the organizations who crafted the various standards don't seem to pay attention to each other.  I'm not saying that I've chosen the best possible names for the metadata tags, but there is a reason for most of the times ExifTool deviates from the names used in the standards documentation.

If you want to add aliases for ExifTool tags, feel free.  There is a user-defined alias feature.

- Phil