when file renaming, creation date changes on some files in finder but reads correct in LR metadata.

[Jimmyfoto]

I ran into this weird scenario and I'm hoping that I can figure out the cause to avoid future incidents.

I'm using LR Classic 7.3.1

Running OSX 10.14.3

Camera: Canon 1D Xmk2

I've downloaded CFast Cards and ingested the files into LR.

I've renamed the files per the client job specs keeping the last digits of the original image number from the camera in the file name.

When viewing the files via LR, it reads the creation date correctly.  But when accessing the files via finder in osx when I'm backing up the job, the creation date has changed to 1/24/1984.

I also kept a copy of the original downloads in another folder and the creation date reads properly there, even on the back ups.  Its just some (NOT ALL) of the renamed files that the creation date changes in the finder only not in LR.

And to complicate things...but for clarity...
As some clients demand to be handed drives at the completion of the shoot, I backed up 3 drives as the shoot was ongoing using the original camera file names as they were shooing with multiple cameras and they wanted to view the files in order of time and date shot.  After the shoot was done, on each of the drives, the files were renamed at separate times using the backed up catalog on each individual drive.  Meaning... drive 1 files were renamed.  Then drive 2.  Then drive 3.
But each drive had the same files where the creation date changed.  Even though the renaming was done for each drive at different times.

Sigh.

Does anyone know, (perhaps an LR engineer) the reason for this occurring, so I can avoid it in the future?

Could this be a LR version thing? 

And for clarity, we had to use LR 7.3.1 because one of the clients "corporate" owned computers couldn't be updated beyond that version.   (Some companies have a complicated IT scenario.) And of course its important for them to be able to see files.  Hence the downgraded version versus the latest/newest option.

Thanks,

Jimmy

[johnrellis]

To make progress on this, we'll have to get more details. There are many different date fields, and I'm not sure precisely which ones you're referring to.  When you say,

when accessing the files via finder in osx when I'm backing up the job, the creation date has changed to 1/24/1984.

are you referring to the "Date Created" that Finder displays?  E.g.

That field is the date maintained by the operating system when a file is created -- it isn't the "capture date" stored in EXIF metadata by cameras.

When viewing the files via LR, it reads the creation date correctly.

Which precise date field in LR's Metadata panel are you referring to?  A screenshot would be best.  (LR doesn't display the file Date Created field that Finder displays.)

[Jimmyfoto]

John.

Yes I'm referring to the date created in the finder.

In LR though... all fields similar read the Mar 24 date,

Those LR fields read: Date Time Original, Date Time Digitized and Date Time. 

You're correct, there is not Date Created Field in the exif.

Im not even sure if this is a LR thing but It only occurred after the renaming.  So I'm baffled.

[Just Shoot Me]

That date in Finder is when the File was created or changed On the Hard Drive. The OS File manager knows nothing about the Digital Image creation date and time, the date and time the image was taken.

This is totally normal and you may even see the Metadata date change in LR.

[Jimmyfoto]

Just Shoot Me.

Very strange then that my copy of the original files that were unrenamed, read correctly in all fields.  And don't have the 1984 date.

[johnrellis]

I'm referring to the date created in the finder. ... In LR though... all fields similar read the Mar 24 date, Those LR fields read: Date Time Original, Date Time Digitized and Date Time.  Im not even sure if this is a LR thing but It only occurred after the renaming. 

The Date Created shown in Finder is the date that the operating system created the file on behalf of any application, and as mentioned before, it isn't the capture date recorded by the camera in EXiF metadata. 

Years ago on Mac, the Date Created would remain unchanged even if applications wrote new versions of the file, but that's long ago ceased being true.  Many apps, including some Apple apps and most Adobe apps, don't preserve Date Created when they modify the file.

Some more questions:

1. Did you rename the files in LR or with Finder or another program? If in LR, did you do it in the Import window or after import with the Library > Rename Photo command?  I don't believe LR should modify the file when it does a rename, but I haven't tested it fully.

2. Did you do the Metadata > Save Metadata To File command, or do you have the option Catalog Settings > Metadata > Automatically Write Changes Into XMP set?  Writing metadata (including Develop settings) back to a file will modify it and often change the Date Created, though not to 1984 unless the clock is set wrong.

3. Is the clock on the computer set to 1984?

4. Did you use an app other than Finder to copy the files between drives or otherwise manipulate the files?

[Jimmyfoto]

John.

The files were renamed using LR after import with original file names and highlighting all files using.

Library:Rename Photos

I didn't save any metadata in the Metadata file command.  And they're not automatically written.  That function is unchecked in catalog settings in the metadata tab.

Clock in computer is set correct local time when it connects to wifi.  Its not set to 1984.  It does adjust to time zones when traveling.

Files weren't manipulated... but were synced via Chronosync for the RAW folder.  Catalog was dragged over separately after syncing was complete.  Then using the dragged over catalog, all files from the shoot were renamed.

I did drag the original files from the cards onto a card download folder.  Once each card was downloaded.  I copied the files to the RAW folder that was already in the catalog.  I then synchronized that folder in Library:Synchronize Folder to display in the library mode.  I did this was the shoot progressed.

Images that were affected were in the 3rd card download of 4.  Not all in files in the 3rd download where affected but it was a group of them only from that card in sequence.  No other files were affected from the other downloads and not all files from the 3rd card were affected.

Could this be a card thing?  And if so... why would the original files that were non renamed or put into the catalog be reading correctly for date created.

[johnrellis]

I think it's unlikely it's LR.  I know of only one circumstance in which it changes Date Created -- when it (sometimes) modifies a JPEG by rewriting a new copy from scratch when it updates the metadata. But in that case, Date Created gets set by Mac OS to the current time, not 1984. And it sounds like you're working with raws, not JPEGs.

I think it's extremely unlikely that it's the memory card -- memory cards store blocks of bytes and are completely unaware of the logical organization of those bytes.  There's no way they could set the Date Created to the same date in 1984.

That suggests some other software as the culprit.  Two hypotheses:

- Perhaps one of the cameras set the Date Created of the photo files it wrote to the card to 1984.  Seems strange, but camera firmware isn't always the most robust.  That Date Created was then preserved as the file was copied from the card and then to the drives.

- Perhaps Chronosync has a bug that wrote the Date Created of 1984.  Apps like Chronosync have to explicitly set Date Created as they transfer files, so it's not inconceivable it has an intermittent, obscure bug.

[Jimmyfoto]

Thank you John.

I appreciate your insight.

I think I may have found where this problem exists.  I found this on another site:

"your Mac could detect the error and set the date the Macintosh was first introduced, January 24, 1984. Many factors can cause this problem, like a fault in the file system entry for the file, or Mac hard drive formatting, interruption in the file or folder copying process, power failure, Mac OS crash, and more"

So I'm thinking this may have occurred unknowingly during the file copying process just before ingesting and renaming in LR. 

It didn't affect the file enough for LR to not understand what it was and was able to rename the file from the original camera name. 

So the only thing that I thought had changed in the file was the naming.  And I assumed the renaming changed the file.

The real tell his is that date.  Jan 24, 1984 as being a Mac thing.

Everything then synced up on each drive as it was.  And all affected files were still dated that way in finder but had no issue in LR.

[johnrellis]

I try to stay on top of metadata issues and all the "magic" dates (1970/1/1, 1980/1/1, 1901 1/1, 1904 1/1, 2038/1/1, 1601/1/1).  But this is the first I've heard of 1984/1/24 showing up in metadata!

The article you found: How to Fix Grayed Out Folders or Files on Mac - EaseUS

[Jimmyfoto]

Thanks John.

I'd be very interested in knowing all about all those other "magic" dates in case I run into them. 

And to be clear, the 1/24 date shows up in Finder on the Mac, versus the metadata field in LR. 

The Date Created field reads the correct date in LR.

[johnrellis]

Operating systems and apps usually represent time as a 32-bit or 64-integer, typically the number of seconds since an "epoch" date. So the time value of 0 will show up as the start of the epoch.  When there are bugs or missing dates, 0 typically shows up, and it gets translated as the start of the epoch.  Some of these dates are:

1601/1/1: Windows

1900/1/1: Windows Excel and newer Mac Excel

1904/1/1: Older Mac versions of Excel

1970/1/1: Unix-based systems (e.g. Linux servers in the cloud)

2001/1/1: Mac OS

2038/1/19: The last date for 32-bit representations of Unix time (2038 could make the Y2K problem look like child's play).

Sometimes you'll see something like 1969/12/31 16:00:00 when the Unix time value of 0 is being displayed in the PST time zone.  In LR, if you see a date of 2000/12/31 or 2001/1/1, that usually indicates a time value of 0 has been stored, probably as the result of a bug or missing data.

[Jimmyfoto]

Thank you for the valuable info.