Using this command exiftool -a -G1 -dateFormat "abc %Y%m%d_%H%M%S" FILE | grep -i date on a specific file, I get the following output:
[System] File Modification Date/Time : abc 20040509_182456
[System] File Access Date/Time : abc 20200717_125617
[System] File Inode Change Date/Time : abc 20200717_125617
[IFD0] Modify Date : abc 20040508_221327
[ExifIFD] Date/Time Original : 0000:00:00 00:00:00
[ExifIFD] Create Date : 0000:00:00 00:00:00
[Composite] Modify Date : abc 20040508_221327
I expected all the dates, including Create Date, to start with abc and be formatted the same. For most files, this is what I experience. But for a specific file, I see the output above. Is this a bug? Is there something else I can do to force the correct format for this one particular file?
The date as written is invalid. There is no month or day 0. Several of the date formats would break if passed 0 month/day, such as %s Unix time.
Interestingly, the error message when trying to write all zeroes with no formatting gives a better error message than a properly formated one
C:\>exiftool -P -overwrite_original -alldates=000000000000 y:\!temp\Test4.jpg
Warning: Month '00' out of range 1..12 in IFD0:ModifyDate (PrintConvInv)
Nothing to do.
C:\>exiftool -P -overwrite_original -alldates="00:00:00 00:00:00" y:\!temp\Test4.jpg
Warning: Invalid date/time (use YYYY:mm:dd HH:MM:SS[.ss][+/-HH:MM|Z]) in IFD0:ModifyDate (PrintConvInv)
Nothing to do.
@jrw: You may want to set the
-api strictdate option to avoid extracting date/time tags which can't be converted properly.
Quote from: StarGeek on January 04, 2025, 10:40:44 AMInterestingly, the error message when trying to write all zeroes with no formatting gives a better error message than a properly formated one
C:\>exiftool -P -overwrite_original -alldates="00:00:00 00:00:00" y:\!temp\Test4.jpg
This is because the date didn't contain a 4-digit year.
- Phil
Quote from: Phil Harvey on January 04, 2025, 11:04:27 AMThis is because the date didn't contain a 4-digit year.
D'OH!
C:\>exiftool -P -overwrite_original -AllDates="0000:00:00 00:00:00" y:\!temp\Test4.jpg
Warning: Month '00' out of range 1..12 in IFD0:ModifyDate (PrintConvInv)
Nothing to do.With and without the
-API StrictDate option (https://exiftool.org/ExifTool.html#StrictDate)
C:\>exiftool -time:all -G1 -a -s -d "abc %Y%m%d_%H%M%S" y:\!temp\Test4.jpg
[System] FileModifyDate : abc 20241208_152321
[System] FileAccessDate : abc 20250104_085832
[System] FileCreateDate : abc 20241123_074915
[IFD0] ModifyDate : 0000:00:00 00:00:00
[ExifIFD] DateTimeOriginal : 0000:00:00 00:00:00
[ExifIFD] CreateDate : 0000:00:00 00:00:00
C:\>exiftool -time:all -G1 -a -s -api StrictDate=1 -d "abc %Y%m%d_%H%M%S" y:\!temp\Test4.jpg
[System] FileModifyDate : abc 20241208_152321
[System] FileAccessDate : abc 20250104_085907
[System] FileCreateDate : abc 20241123_074915
@Phil Harvey: Thanks for that tip. I will use the -api StrictDate=1 option. However, it seems that a date tag's output should never ignore -dateFormat when specified, even if the date/time input is invalid. In my case, my script broke due to this. Should I report a bug against this issue? I'd be ok with any of several alternative ways of handling the output in this case (e.g. use a default date such as the epoch, skip outputting the date tag, print a warning, etc). BTW, thanks for writing such a useful tool!
@StarGeek: It took me a minute or two to see what you did there, changing StrictDate to StrictDates to make it invalid (and consequently ignored). May I suggest something like xStrictDate to make it more obvious to the inexperienced reader (me) what you're doing? I kept trying to figure out why my test case couldn't replicate yours, until I saw that subtle difference. It was helpful to see how -time:all could effectively replace my grep. And I learned about -s, which I now notice is mentioned in the FAQ.
Quote from: jrw on January 04, 2025, 02:13:46 PMit seems that a date tag's output should never ignore -dateFormat when specified
1. The standard date/time library functions used by ExifTool will not format an invalid date.
2. It would actually be impossible to determine the values for some of the date/time formatting codes for an invalid date.
QuoteIn my case, my script broke due to this.
I suggest using the StrictDate option then.
QuoteShould I report a bug against this issue?
No. There is no way I can fix this without implementing all of the standard date/time library functions myself, which would be a lot of work.
- Phil
Quote from: jrw on January 04, 2025, 02:13:46 PM@StarGeek: It took me a minute or two to see what you did there, changing StrictDate to StrictDates to make it invalid (and consequently ignored). May I suggest something like xStrictDate to make it more obvious to the inexperienced reader (me) what you're doing?
Copy/paste error. I was trying to show with and without
-API StrictDate option (https://exiftool.org/ExifTool.html#StrictDate). Fixed.
@Phil: I will definitely use the StrictDate option.
But I would think that you could detect when an invalid date was given as input (because the library functions would report a failure). In that case, if -dateFormat had been specified, rather than output a date which doesn't conform to the specified -dateFormat template, take some other action, like omitting that tag altogether or using using a default datetime value (like the Epoch) or, at a minimum, emitting a warning.