My goal with my pictures was: To have all pictures sortable by snap time with standard file browser means .
File browser sorts by date by default with modification date and I arranged exif metadata so
that even scanned old pictures had their estimated snap times set in the CreateDate Tag
Then I used exiftool -filemodifydate<createdate command - it worked with exception to the year e.g. 1969.
I did small research and got the strange behaviour for more years.
Copy CreateDate to FileModifyDate works fine for years till 1899 and from 1973 further.
The year 1900 is copied to FileMOdifyDate as 1800 - the date exactly 100 years less.
The years 1901 till 1972 are copied with 100 years less but also one day less
I have run the exiftool 12.51 on Windows 10 Home Version 22H2 19045.2251,
with the bash installed by GIT: GNU bash, version 4.4.23(1)-release (x86_64-pc-msys), git version 2.32.0.windows.2
perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-msys-thread-multi
Basic commands of the test are: set generated createdate to an image, show it, copy createdate to filemodify date, show it.
The exiftool output is then collected to one row.
The basic commands are then looped through the given years range.
Final output is for readability shortened.
My question is what i am doing wrong or is there any workaround?
I have plenty photos falling with the snap time to the failing year range.
Goza
The test bash script:
for n in {1898..1974} ; do
exiftool -createdate=$n.01.01-13:59:59 -execute \
-createdate -execute \
-filemodifydate\<createdate -execute \
-filemodifydate -common_args -args -q 20170217_160157.jpg \
|tr -d '\r' |tr '\n' '\t'; echo ' '$n;
done
-CreateDate=1899:02:15 13:00:00 -FileModifyDate=1899:02:15 13:00:00+01:00 1899
-CreateDate=1900:02:15 13:00:00 -FileModifyDate=1800:02:15 13:00:00+01:00 1900
-CreateDate=1901:02:15 13:00:00 -FileModifyDate=1801:02:14 13:00:00+01:00 1901
-CreateDate=1902:02:15 13:00:00 -FileModifyDate=1802:02:14 13:00:00+01:00 1902
-CreateDate=1903:02:15 13:00:00 -FileModifyDate=1803:02:14 13:00:00+01:00 1903
-CreateDate=1904:02:15 13:00:00 -FileModifyDate=1804:02:14 13:00:00+01:00 1904
...
-CreateDate=1972:02:15 13:00:00 -FileModifyDate=1872[/color]:02:14 13:00:00+01:00 1972
-CreateDate=1973:02:15 13:00:00 -FileModifyDate=1973:02:15 13:00:00+01:00 1973
-CreateDate=1974:02:15 13:00:00 -FileModifyDate=1974:02:15 13:00:00+01:00 1974
When I tried set the tag under another date format -d "%s" -filemodifydate\<createdate -execute the behaviour for some years changed:
Warning: Can't convert negative epoch time in File:FileModifyDate (PrintConvInv) - 20170217_160157.jpg
Warning: No writable tags set from 20170217_160157.jpg
-CreateDate=1969:02:15 13:00:00 -FileModifyDate=2022:11:28 13:20:04+01:00 1969
-CreateDate=1970:02:15 13:00:00 -FileModifyDate=1870:02:13 12:00:00+01:00 1970
-CreateDate=1971:02:15 13:00:00 -FileModifyDate=1871:02:13 12:00:00+01:00 1971
-CreateDate=1972:02:15 13:00:00 -FileModifyDate=1872:02:13 12:00:00+01:00 1972
-CreateDate=1973:02:15 13:00:00 -FileModifyDate=1973:02:15 12:00:00+01:00 1973
It seems to me that something is wrong in perl date conversion
Operating systems in general can't handle dates much outside the range where computers existed.
- Phil
Hi Phil,
Thanks it may be so, the UNIX epoch starts at 1970-01-01 and therefore 1969 is negative.
It's pity, as the windows has time zero at 1 January 1601 00:00:00 UT as reckoned in the proleptic Gregorian calendar (https://en.wikipedia.org/wiki/System_time).
I understand that one can do with it nothing beside the workarounds.
The unix touch on msys works to change file modification date to values below 1970, while it uses structural date representation.
I think, to allow same possibility by setting date tag in exiftool would be sufficient.
I.e. FileModifyDate="1969-..." without the conversion to machine represantation and back?
My previous solution used the touch, but it was wery slow using the generated script of touches. When I moved all code to the exiftool alone (I appreciate its strengths :-) ), the performance raised significantly.
What do you think?
Goza
The problem is that ExifTool uses the standard C date/time libraries which have historically been restricted to the range 1970-2038.
- Phil
It should also be noted that the minimum date exhibits a yearly creep up in the earliest date usable. My previous post (https://exiftool.org/forum/index.php?topic=11299.0) on the subject.
Currently, dates before 1973:01:01 00:00:00 will have inaccurate results. I suspect this will change on January 1st.
I had forgotten about that creep. I have no idea what could be causing this.
- Phil