Is there a SetFile Date limitation workaround

When running the following AppleScript (other portions were removed for clarity)…

set newDate to "1/1/1953 00:00 AM"

do shell script "SetFile -d " & quoted form of newDate & " " & quoted form of filePath

I can change  the created date to any year from 1970 to 2079 but attempting any year outside that range returns unpredictable results.  For instance, using 1/1/1953, the created date became February 6, 2096. But if I enter 1/1/2096 the created date becomes September 3, 2061. Any year between 1970 and 2079 yields the correct result.

So, what’s the workaround? I need to be able set the year to any date from 1920 to the present and SetFile apparently can’t handle that range. 
After doing some research it appears this may have something to do with Unix/Posix Epoch time (1970 - 2038). If that’s the case then there’s no work around. You can’t use any year outside that range.
So, if you have a few thousand scanned photo files from the 20’s, 30’s, 40’s, 50’s and 60’s like I do you can’t set the create date to reflect when the photo was taken. Only the day it was scanned.

After doing some research it appears this may have something to do
with Unix/Posix Epoch time

Not quite. Modern macOS file systems are capable of storing a creation day far outside of the traditional UNIX epoch. For example, this code will happily set the creation date back to 1910:

Code Block
func setCreationDate(_ date: Date, for url: URL) throws {
var url = url
var rv = URLResourceValues()
rv.creationDate = date
try url.setResourceValues(rv)
}


The problem you’re having is that SetFile is a legacy tool layered on top of legacy APIs )-:

So, if you have a few thousand scanned photo files from the 20’s,
30’s, 40’s, 50’s and 60’s like I do you can’t set the create date to
reflect when the photo was taken. Only the day it was scanned.

Honestly, I think that setting it to the scanned date is correct. That’s the date that the file was created. It’d be better to find a different way to represent the date that the photo was taken. Trying to conflate the two will cause all sorts of problems:
  • Two scans of the same photo will have the same creation date, which doesn’t make logic sense.

  • A file creation date includes a time, and you’re unlikely to have that info.

  • A lot of the time you don’t have exact dates. For example, you might know the day and month but not the year, or the month and year but not the day. You can’t represent that sort of ambiguity in a file creation date.

  • If your date ranges extend back to 1920 then you might be looking at a Julian date!

Have you looked at other standards for this? I’d be surprised if the folks working on Exif hadn’t considered this issue in depth.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Again, thank you. Second time you've given me good insight.

I wouldn't have gone down this path if it wasn't for the way dates are (or are not) captured during scanning as well as how Apple Photos imports images. There have even been times when the camera, scanner or Photos app has butchered the create date on import.

Philosophically, I agree with your observation that the file create date is indeed that and should be sacrosanct. But I can't control what date Photos uses on import. I'd love to direct it to use a specific EXIF tag.

Bottom line...I've got over 34,000 images in the photos app and adding another 4-5,000 shortly. Importing photos that were taken several decades ago and giving them a current date of the scan doesn't allow me to sort the images chronologically which can be a monumental hassle when you're looking for something specific. Photo's of my great grandparents in 1890's mixed in with photos of my kids in 70's and 80's. It becomes a mess quickly.

Apparently, Apple has recognized this problem and Photos does allow you to manipulate the create date manually after import but its tedious and inefficient to change thousands of photos that way. So, I figured since the file name has the year the photo was taken, if I change the file create date to match before import, I'd be saved myself allot of time making manual updates later. It's not a perfect solution since in many cases I don't know the exact day or time the photo was taken, but it does get my photos into the proper order by year.

Anyway, many thanks for the assist and the code sample... I'll be experimenting with it shortly.


I have a MacOS app in the store that tries to address the issues related by starkadhr, and some potential customer (probably some Unix guy) asked whether the app could change the creation date/year of, again, scanned photos before 1/1/1970. No. With Eskimo's reservations about changing creation dates noted, I changed the creation date my old-fashioned way in ObjC (I don't do Swift - I'm passed my prime since I had one of the first 500 apps in the app store).

NSDictionary *fileDict = [NSDictionary dictionaryWithObjectsAndKeys:createDate, NSFileCreationDate, modDate, NSFileModificationDate, nil];
[[NSFileManager defaultManager] setAttributes:fileDict ofItemAtPath:[self.urlForCurrentImage path] error:nil];

I'm wondering if this ObjC code below will work with earlier dates than 1970 or is this still using setFile/old Unix code somehow?

- (BOOL)setUnixSafeFileCreationDate:(NSDate *)date fileURL:(NSURL *)url {
	NSError *error = nil;
	BOOL success = [url setResourceValue:date
                                    forKey: NSURLCreationDateKey
                                     error:&error];
     if (!success) {
        NSLog(@"NSURLCreationDateKey error: %@", error);
            return false;
     } else {
           return true;
     }
}
Is there a SetFile Date limitation workaround
 
 
Q