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"