Research precedence order (i.e. modification date vs original date)

Hey,

Hope you’re well

Thanks for software as always

I’m observing some strange behaviour today where the following Exif[f] seems to get higher precedence:

File Modification Date/Time     : 2017:04:02 03:13:53+02:00

… over the following Exif:

Date/Time Original              : 2012/03/02 11:56:41
Create Date                     : 2012/03/02 11:56:41

Inevitably, this results in incorrectly named files and folders (e.g. 2017-04-02_00-11-29-2012-03-02_12-56-42-imag0720.jpg)

Is this expected behaviour?:

If yes, why

If no, what do you need to debug this

If you have any issues (e.g. questions/queries) - happy to help

Hope this is clear/useful and to hear back

Keep up great work!

Yours faithfully

[f]

Last login: Sat Sep 15 01:33:22 on ttys001
Lewiss-MacBook-Pro:~ ldexterldesign$ exiftool /Applications/elodie/-2-destination/2017-04/HTC/Unknown\ camera\ model/UK\ -\ England\ -\ /2017-04-02_00-11-29-2012-03-02_12-56-42-imag0720.jpg
ExifTool Version Number         : 11.01
File Name                       : 2017-04-02_00-11-29-2012-03-02_12-56-42-imag0720.jpg
Directory                       : /Applications/elodie/-2-destination/2017-04/HTC/Unknown camera model/UK - England -
File Size                       : 810 kB
File Modification Date/Time     : 2017:04:02 03:13:53+02:00
File Access Date/Time           : 2018:09:15 01:33:14+02:00
File Inode Change Date/Time     : 2018:09:15 01:33:13+02:00
File Permissions                : rwxr-xr-x
File Type                       : JPEG
File Type Extension             : jpg
MIME Type                       : image/jpeg
Exif Byte Order                 : Big-endian (Motorola, MM)
Make                            : HTC
Camera Model Name               : HTC Sensation Z710e
X Resolution                    : 72
Y Resolution                    : 72
Resolution Unit                 : inches
Y Cb Cr Positioning             : Centered
ISO                             : 87
Exif Version                    : 0220
Date/Time Original              : 2012/03/02 11:56:41
Create Date                     : 2012/03/02 11:56:41
Components Configuration        : Y, Cb, Cr, -
Focal Length                    : 4.3 mm
Flashpix Version                : 0100
Color Space                     : sRGB
Exif Image Width                : 1840
Exif Image Height               : 3264
Interoperability Index          : R98 - DCF basic file (sRGB)
Interoperability Version        : 0100
GPS Latitude Ref                : North
GPS Longitude Ref               : West
GPS Altitude Ref                : Above Sea Level
GPS Time Stamp                  : 11:56:30
GPS Processing Method           : ASCII
GPS Date Stamp                  : 2012:03:02
Compression                     : JPEG (old-style)
Thumbnail Offset                : 854
Thumbnail Length                : 13830
XMP Toolkit                     : Image::ExifTool 10.40
Original File Name              : 2012-03-02_12-56-42-imag0720.jpg
Image Width                     : 1840
Image Height                    : 3264
Encoding Process                : Baseline DCT, Huffman coding
Bits Per Sample                 : 8
Color Components                : 3
Y Cb Cr Sub Sampling            : YCbCr4:2:0 (2 2)
GPS Altitude                    : 0 m Above Sea Level
GPS Date/Time                   : 2012:03:02 11:56:30Z
GPS Latitude                    : 51 deg 28' 12.64" N
GPS Longitude                   : 2 deg 35' 39.97" W
GPS Position                    : 51 deg 28' 12.64" N, 2 deg 35' 39.97" W
Image Size                      : 1840x3264
Megapixels                      : 6.0
Thumbnail Image                 : (Binary data 13830 bytes, use -b option to extract)
Focal Length                    : 4.3 mm

[jmathai]

That makes sense. We can output a warning in case the EXIF field is not empty but doesn’t pass validation. Reopening.

[ldexterldesign]

If I were elodie I would throw an error

Apologies, although I said error I meant some kind of general exception

Assuming error means something that stops the CLI how about a warning (i.e. something that doesn’t stop the CLI) - the warning could mention a lower priority piece of data was used because the top priority data was invalid?

My use case here is that if I’m inputing lots (e.g. 1000+) of files anything that takes an incorrect date gets buried in my output in the wrong folder structure. Until I I find the file later I have no idea it’s there and actionable (i.e. needs correct Exif); by which point if I used the --trash option then I’ve just lost the original folder structure with naming potential that may have been useful to me in identifying and correcting the incorrectly dated file.

If you have any issues (e.g. questions/queries) happy to help

Hope this is clear/useful and to hear back

Yours faithfully