Date bug 1960 -> 2060

[marchyman]

Exiftool somehow converts 1960 to 2060 on some date fields.  I thought this was a bug in my program, but found I can reproduce the issue from the command line.

Machine: Mac running 10.13.6
Exiftool version 11.08.  The problem also occurred on version 10.94

This command line:

exiftool "-q" "-m" "-overwrite_original_in_place" "-GPSLatitude=37.678168563656385" "-GPSLatitudeRef=N" "-GPSLongitude=122.46323209041337" "-GPSLongitudeRef=W" "-GPSDateStamp=1960:01:01 12:00:00 -08:00" "-GPSTimeStamp=1960:01:01 12:00:00 -08:00" "-DateTimeOriginal=1960:01:01 12:00:00" "-DateTimeOriginal>FileModifyDate" "-GPSStatus=" P1000686.JPG

resulted in some three fields having a 2060 date.

File Modification Date/Time   : 2060:01:01 12:00:00-08:00
GPS Date Stamp                  : 2060:01:01
GPS Date/Time                    : 2060:01:01 20:00:00Z

It looks like the File Modification Date/Time depends upon the date before updating.  I re-ran the test using 1969:01:01 and only the File Modification was incorrect.   Running the test with a 1969 date a second time resulted in proper dates.

[StarGeek]

Previous threads on the subject:
Interesting results changing file system dates 1969 to 1968, and 1980 to 1979
Use of FileModifyDate not working in my batch job
Windows FileAccessDate, FileCreateDate, and FileModifyDate wrong century

tl;dr,
ExifTool uses standard Perl date/time routines to do the necessary conversions.  These routines are based on an epoch date of 1970, and the behaviour before that can be funny.

[StarGeek]

I just noticed that I had overlooked the fact that there was a problem with the GPSDateStamp as well.  I had just assumed that it was about the file system dates.  My mistake.

There does seem to be a problem with setting the GPSDateStamp.  The addition of the TZ causes the jump.  In this example, GPSTimeStamp was previously set using the same date with the time zone with no problem.

Code Select Expand

C:\>exiftool -P -overwrite_original "-GPSDateStamp=1960:01:01 12:00:00-8:00" y:\!temp\Test3.jpg 
    1 image files updated

C:\>exiftool -g1 -a -s -GPSDateTime -GPSDateStamp y:\!temp\Test3.jpg
---- GPS ----
GPSDateStamp                    : 2060:01:01
---- Composite ----
GPSDateTime                     : 2060:01:01 20:00:00Z

C:\>exiftool -P -overwrite_original "-GPSDateStamp=1960:01:01 12:00:00" y:\!temp\Test3.jpg 
    1 image files updated

C:\>exiftool -g1 -a -s -GPSDateTime -GPSDateStamp y:\!temp\Test3.jpg
---- GPS ----
GPSDateStamp                    : 1960:01:01
---- Composite ----
GPSDateTime                     : 1960:01:01 20:00:00Z

[Phil Harvey]

Right.  There are problems when ExifTool has to use the C time library functions to adjust a date/time outside the range 1970-2034, which it has to do to adjust for the time zone in your first example.

- Phil

[heatvent]

Hi, is there a workaround for this issue?

[StarGeek]

In the case of GPSDateStamp, don't include the time zone.  All that's needed for that tag is just the date anyway.

For the case of  FileAccessDate, FileCreateDate, and FileModifyDate, you have to use a different program.  For the OP, marchyman, since they're on a Mac, they would use touch (as would someone on linux).   On Windows, you would have to use Powershell or look for a utility (see this SuperUser answer).  Weird, it looks like Windows doesn't have a native program to do so.

But the thing is, why do you want to change this metadata to a time where the file could not possibly exist?  Any sorting can be done on the embedded metadata such as DateTimeOriginal.  In Windows you would just sort on the "Date Taken" property and I'd be surprised if you couldn't do something similar on Mac/Linux.  Most websites I've tested (that don't strip away metadata) would sort on that tag as well, as would most DAM (Digital Asset Management) software.

And the File*Date tags are fragile and easily changed by any program that opens them for writing, even if nothing is changed.

[heatvent]

But the thing is, why do you want to change this metadata to a time where the file could not possibly exist?  Any sorting can be done on the embedded metadata such as DateTimeOriginal.  In Windows you would just sort on the "Date Taken" property and I'd be surprised if you couldn't do something similar on Mac/Linux.  Most websites I've tested (that don't strip away metadata) would sort on that tag as well, as would most DAM (Digital Asset Management) software.

In my case, I scanned old slides to digital.  The create date is sometime in 2013.  Just neater to have the create date be something that makes sense when the photo was taken as to avoid issues with any programs or sorting that happens based on create date.  In other words, it's more organized.

[StarGeek]

The create date is sometime in 2013.

Exiftool will properly set File*Date dates to 2013.  The problem comes up when you set the date to something between 1900:01:01 00:00:00 and 1968:12:31 23:59:59 (see the first link in my post above).

Just neater to have the create date be something that makes sense when the photo was taken as to avoid issues with any programs or sorting that happens based on create date.  In other words, it's more organized.

I understand  that, but I have yet to find a program that sorts by date that doesn't use the embedded dates.  Honest question, do you have such a program?  I like to keep track of such things as I like to test out the metadata capabilities of various programs.

[G2]

A note about GPS Date and Time.

GPS time starts on Midnight of January 5, 1980 UTC, which is the 0 seconds of GPS time. So, strictly speaking, setting GPSDateStamp to any date prior to that one makes no sense if this information is used for any GPS related processing.

Also note that as of today (August 17,2018), the GPS satellites clocks are running 18 seconds ahead of UTC. These are called Leap Seconds that need to be substracted to obtain the correct UTC time. The reason of this discrepancy is that UTC is adjusted from time to time skipping or adding a second to keep it in sync with the actual rotational speed of the Earth, which has small variations over time, while GPS atomic clocks are kept running unaltered since their start date.

[Phil Harvey]

Interesting.  You are right of course, and this is a good thing to keep in mind if you are concerned about an accurate absolute time.

- Phil