exif datetime vs iptc datetime

[Bob M]

It appears that photomechanic does not respect the difference between the exif date and time and the iptc date and time.  It appears that iptc time and date defaults to the exif values when no iptc time and dates have been explicitly entered.  This strikes me as inapprorpriate.  In most cases these datetimes are the same, but for example, they are not for scanned photos where the exif date/time refers to when the image was scanned, not when it was taken.  I would like the iptc date/time to remain undefined for scanned photos when I don't know, or haven't yet filled in, when the photo was taken.  It seems to me that these variables are distinct from each other and should  remain so.  It is convenient to have the iptc datetime default to the exif ones, but that should happen only when I explicitly tell it to.

Along the same lines, I note that the xml exporter exports the exif date and time, but not the iptc date and time. 

[Kirk Baker]

It appears that photomechanic does not respect the difference between the exif date and time and the iptc date and time.  It appears that iptc time and date defaults to the exif values when no iptc time and dates have been explicitly entered.  This strikes me as inapprorpriate.  In most cases these datetimes are the same, but for example, they are not for scanned photos where the exif date/time refers to when the image was scanned, not when it was taken.  I would like the iptc date/time to remain undefined for scanned photos when I don't know, or haven't yet filled in, when the photo was taken.  It seems to me that these variables are distinct from each other and should  remain so.  It is convenient to have the iptc datetime default to the exif ones, but that should happen only when I explicitly tell it to.

We don't agree on this.  Why is this a problem?  You can easily change the IPTC date to anything you wish.

-Kirk

[Bob M]

I posted this in the discussion section rather than the support section because I see this as a minor bug rather than a show stopping problem.  But I do see it as a bug.

I am a new user of PM and I am still casting about as to how I will be using PM,  how to best set up my file system etc. before pulling over my 40,000 picture archive (I anxiuosly await your DAM solution).  In any event, I was thinking of archiving photos in directories defined by the "photo date", that is, the date that is depicted in the photo.  I wanted to use the IPTC date to store the photo date (I believe that is a conventional use of that field).  But because of the presence of scanned photos in my archive, the photo date is not always the exif date and in some cases it is undefined.  I realize that I have the ability to set the IPTC date to whatever I want (up to a point),  But I don't have the ability to leave that field blank.  (I need that field to be blank for those cases when I don't know the photo date.)  If I try to leave it blank PM fills it in with the EXIF date.  If the EXIF date is blank, it fills it in with the current date.  That behaviour strikes me as perverse.  And it is compounded by the fact that the IPTC stationary pad has a check box beside "date".  One would reasonably expect that if that box were unchecked, the variable would not be set, but that is not the case.

I can get around the issue.  I can define some arbitrary date to stand in for undefined photo dates.  This will work, but it is a bit of a kludge.  As an experiment, I tried to set the iptc date to 0000 01 01 (that is a date that is obviously not a believeable date), but PM would not allow that.

It strikes me as a poor design decision to not allow the iptc date to remain unset.  That this is the case is not obvious nor expected.

But don't misunderstand; I still think PM is an excellent piece of software.