Setting FileModifyDate on scanned files has 100 year offset

[Dagius]

I am scanning and digitizing many old family slides and photographs, which are very old. I am trying to use exiftool set the image dates to the date(s) the photos were taken and then upload to Google Photos. Not sure which date is important so I am setting several as you can see this example.

exiftool -d "%%%%Y:%%%%m:%%%%d %%%%H:%%%%M:%%%%S" -DateTimeOriginal="1946:06:22 06:30:05" -CreateDate="1946:06:22 06:30:05" -FileModifyDate="1946:06:22 06:30:05" -ModifyDate="1946:06:22 06:30:05"    -ImageDescription="1940s slides" R1-1946-06-22-0001.jpg

I am having the same problem that Fererico had: in Windows 10 the set date years are 100 years off. In the example above the year displayed by Windows after I run the command is "1846"! https://exiftool.org/forum/index.php?topic=11478.0

Directory of P:\Digitize\images

06/21/1846  06:30 AM           730,936 R1-1946-06-22-0001.jpg
               1 File(s)        730,936 bytes

Strangely, when I examine the dates with exiftool -AllDates they look OK. [Edit: Also, when I upload to Google Photos, the displayed year is correct]
>exiftool -AllDates R1-1946-06-22-0001.jpg
Date/Time Original              : 1946:06:22 06:30:05
Create Date                     : 1946:06:22 06:30:05
Modify Date                     : 1946:06:22 06:30:05

It seems that setting FileModifyDate causes the problem, but when I skip setting that Windows 10 displays the current date (year=2021). That is annoying because I want to be able to sort and organize my photos by date on Windows. (I upload to Google Photos, but don't trust them to be the main repository).

How can I fix this so that Windows will display the correct date-taken year?

[Phil Harvey]

You can't expect fictional file modification date/times like this to work properly.  Generally, only dates between 1970 and 2038 should be used.  Ones outside this range may work on some systems but not others.

- Phil

[StarGeek]

Previous post on the subject

The current range that can't be set for the file system timestamps is from 1900:01:01 00:00:00 to 1971:12:31 23:59:59.

I am scanning and digitizing many old family slides and photographs, which are very old. I am trying to use exiftool set the image dates to the date(s) the photos were taken and then upload to Google Photos. Not sure which date is important so I am setting several as you can see this example.

For most image files, setting AllDates should be enough.  That is a shortcut that will fill the CreateDate, DateTimeOriginal, and ModifyDate tags.  Google photos will read all three of them.

See this post for a list of all the timestamp tags Google Photos will read.  Google doesn't give a priority to any of these tags except the last two, which are always the last tags read.

That is annoying because I want to be able to sort and organize my photos by date on Windows. (I upload to Google Photos, but don't trust them to be the main repository).

Right click the header column on the directory window, select more, scroll down to "Date Taken" and select that.  That will give you a "Date Taken" column for images that you can sort on.

It's been a while since I've checked but when I last did, there really wasn't any easy way of batch setting the file system timestamps on Windows, other than exiftool.

[obetz]

Previous post on the subject

The current range that can't be set for the file system timestamps is from 1900:01:01 00:00:00 to 1971:12:31 23:59:59.

on my system, the 1946 date is also 100 years off, but setting a 1964 or 1968 date seems to work with a "dir" command in a command window.

But the Windows Explorer listing doesn't show a date for the 1964 or 1946 file (see screenshot). Right click -> properties does show the correct 1964 date but 1846. Weird.



Same results with my Strawberry Perl 32 and 64 bit builds.

[Dagius]

Thanks to all for your replies to my question.

So, it looks like I cannot depend on Windows to handle old image file dates correctly. This is somewhat surprising, because Microsoft documentation implies that their file system dates are handled as 64-bit objects and can be used to enumerate date-times in 100-nanosecond increments back to the year 1601!
https://docs.microsoft.com/en-us/dotnet/api/system.datetime.tofiletime?view=net-5.0

Fortunately there are workarounds for this problem. Google Photos seems to work OK. And I have found a Python utility called 'sortphotos' which uses EXIF dates stored in the image file to create photo archives in Windows 8/10, sorted by year and month. It also seems to work OK and has several options to specify date formats.
https://github.com/andrewning/sortphotos

So I can work around this horrible 'bug' in Windows.

Thanks again.

[StarGeek]

So I can work around this horrible 'bug' in Windows.

As per my link, the bug is in Perl.  And for images/videos, the EXIF/Quicktime timestamps are the appropriate places to set the date.  Being able to set a file system timestamp to the 1600s is silly because, simply put, computer files did not exist then.

[flug]

I just ran up against this, so I thought I'd drop in my $0.02.

First off, it turns out the issue is not dates before 1/1/1970.

Rather it is the the date functions used in Perl can only handle a 100 year period, so that 100 year period is a moving window around the current year - so -50 years and +50 years or thereabouts.

The trouble we are running into then, the year year 2024, is that we can't enter file creation/modifications dates before 1/1/1974 (50 years ago).  Or maybe it is 1/1/1975 - I didn't bother testing it that closely.

More details about the issue here and workable solutions for dealing better with dates in perl here, for anyone interested.

So there is some sense in saying, well there were no computer files before 1970, and Unix etc can't handle those dates anyway, so no need for those dates to be available on the file system.

But . . . as we approach the year 2025 and then 2030 (meaning that 50 years ago will soon be 1975 and then 1980), without getting persnickety about it - because of course computer files in some form go back at least to the 1940s - I personally have computer files on the shelf not 3 feet from me right now, with perfectly valid creation and modification dates in the late 1970s.

Within just a few years, those dates won't be available for use.  And thinking about it, I am quite sure there are some graphics and image files on those disks and tapes.  (I only wonder what format they would be in . . . long before GIF and such had been invented.  My only distinct memory is writing things like dumping the entire graphics area to disk.  But we didn't call it anything special and it certainly didn't have any metadata!)

So I know it is a giant pain to make any change to a well tested piece of software, but it might be time to start thinking about it.

And I wanted to make it clear to anyone else looking at this, that the "danger date" is not 1/1/1970 or any other such fixed date, but rather January 1st of the year 49 or 50 years ago from the present time.