Using SetFile to change file creation date produces wrong date

If you read the man page for SetFile, it states that the date must be in the UNIX Epoch timeframe (1/1/1970 - 1/18/2038) — because macOS is a UNIX operating system. Your 1948 year value sends SetFile into a deranged fit.

FileCreateDate 1970:01:01 00:00:00 UTC is the earliest date macOS 14 (or any UNIX?) supports. Some apps like GraphicConverter might temporarily set it to an earlier date in Finder dates but usually after a reboot it is changed to some weird future date.

On the other hand, the earliest FileModifyDate seems to be something like 1677:09:21 01:52:33+01:40 (YMMV, the exact time might depend on your location and timezone).

In movies the earliest QuickTime:CreateDate is 1904:01:01 01:39:50+01:39 (again YMMV).

In movies as early as Keys:CreationDate 0001:01:01 00:00:00 works for Photos.app. Google Photos might randomly display a wrong date and even if it displays the correct date, it might sort that movie incorrectly so I use 1902 as the earliest date in Google Photos.

In images ExifIFD:DateTimeOriginal 0001:01:01 00:00:00 seems to be the earliest that Photos.app supports. Google Photos accepts EXIF dates after 01.01.1902 (EXIF date 01.01.1901 08:00:00 is displayed as 06.12.1969 21:09:00).

BTW Windows seems to have yearly creep with the file system timestamps. A few months ago the date had crept up to 1973:12:31 23:59:59.

https://exiftool.org/forum/index.php?topic=15354.msg82435#msg82435

Another approach is to use Apple's Preview to assign that data string as a new PDF keyword attribute via the Inspector panel.

Once that is done, you can locate that PDF easily with the following Spotlight search:

I suggested the PDF Keyword attribute as it is within the PDF and not associated with the file as an extended attribute (e.g. Finder comment). The latter can get stripped from a document depending on its cross-platform travels, but the internal PDF keyword attribute is immune.

The Touch command makes no date range condition, and is unrelated to SetFile. No operating systems existed in 1948 making that choice in a file date/time stamp precarious at best. Have a backup of that file in case future operating system releases rebell at that choice of using an improbable file date.

Thanks for the note about adding Keywords to .pdf via Preview.app.

I have been using exiftool for this. Preview.app can read them and vice versa.

Writing Keywords as a comma-separated list to .pdf metadata can be done in exiftool with the following command:

exiftool -overwrite_original_in_place -sep ', ' -PDF:Keywords='Keyword 1,Keyword 2' a.pdf

Which reads as:

exiftool -a -G1 -s a.pdf                                                        
[PDF]           Keywords                        : Keyword 1, Keyword 2

Add Keywords:

exiftool -overwrite_original_in_place -sep ', ' -PDF:Keywords+='Keyword 3,Keyword 4' a.pdf

exiftool -a -G1 -s a.pdf                                                                 
[PDF]           Keywords                        : Keyword 1, Keyword 2, Keyword 3, Keyword 4

Remove a Keyword:

exiftool -overwrite_original_in_place -sep ', ' -PDF:Keywords-='Keyword 2' a.pdf

https://exiftool.org/TagNames/PDF.html

Thanks for showing the ExifTool approach to PDF keyword metadata handling. I have a Python3/Objective-C application that does this written long ago, and was considering a new Swift alternative, and this resolves that sharp pencil in the side of the head coding effort.

I gave an example of a Spotlight (or Finder Window Search field) query for a PDF keyword.