year-only dates for Create Date field

[carlseibert]

Hi,

We seem to be having an epidemic of users who need to do dates that are only years when the exact create date is unknown. (As with historical photos.) David Riecks has two on his mailing list right now and I just finished corresponding with a reader from my blog.

It appears that the IPTC has just changed the implementation notes for the Create Date field to allow for inexact dates:

Note 2: Software showing the metadata user interface should adopt a widget for this property that supports editing truncated dates, like year and month only, or year only. Software embedding truncated dates as IIM DataSet 2:55 should use the value "00" for undefined days or months (like "19180000" for an image taken "in the year 1918")

I don't know what the best or most elegant solution might be. Allow zeros for month and day, maybe? I have opined that all historical photos need a time element in their captions, regardless. Even more so because publishing systems often programmatically create create dates, working from metadata like the file C time or the Exif "original" date, which are out of photographers' normal control.

-Carl

BTW, David says he's the one who urged the new stance in the most recent version of the standard. Credit where it's due....

[Kirk Baker]

Carl,

We seem to be having an epidemic of users who need to do dates that are only years when the exact create date is unknown. (As with historical photos.) David Riecks has two on his mailing list right now and I just finished corresponding with a reader from my blog.

It appears that the IPTC has just changed the implementation notes for the Create Date field to allow for inexact dates:

Note 2: Software showing the metadata user interface should adopt a widget for this property that supports editing truncated dates, like year and month only, or year only. Software embedding truncated dates as IIM DataSet 2:55 should use the value "00" for undefined days or months (like "19180000" for an image taken "in the year 1918")

I don't know what the best or most elegant solution might be. Allow zeros for month and day, maybe? I have opined that all historical photos need a time element in their captions, regardless. Even more so because publishing systems often programmatically create create dates, working from metadata like the file C time or the Exif "original" date, which are out of photographers' normal control.

We would have to either abandon the OS-supplied "Date Picker" control or add some checkboxes "Inexact month", "Inexact day" that allows choosing an exact date (what the picker only allows) but zeroes out the month/day when written.

Neither are likely to be done soon, unfortunately.

-Kirk

[carlseibert]

Hi Kirk,

That's pretty much what I thought.

And this is just me talking here. This may be a giant deal to some stakeholders. But as far as I'm concerned, given the issues that happen downstream when publishing CMSes get ahold of the picture and the strong/neigh on to absolute need to be explicit about the time element in the caption on historical photos, it's not urgent by any means. (I have just used January 1 in this case for decades.)

That said, when the time comes, I'd vote for some sort of tickbox to temporarily turn off date validation or another choice in the flyout for what type of date the user wants (Today, Date Created, Date Modified, etc) for "Year Only" or something similar.

Cheers.

-Carl

[carlseibert]

Hi again,

... just had another thought. Assuming that you had a provision to add some sort of year-only date to the field, what happens in the future when a user searches a date range, expecting that image to return.

In your own program, you could just have code to include dates that have "00" months or whatever.

But what about other developers? Maybe such a date would fail some validation routine that they use and not return. Thus turning that photo into a big, fat piece of lost data.

Yipes!

And what if some other developer uses a different way of expressing year-only dates and images encoded by their software ends up in a PM+ archive? Double yipes.

Maybe the IPTC needs to explicitly specify how this should be done. And all the DAM and photo management programs developers would somehow adhere to the standard. And.....  Maybe it's best for users to just continue to mark historical photos as "January 1 or whatever year" and leave well enough alone.


-Carl

[Kirk Baker]

Carl,

Maybe the IPTC needs to explicitly specify how this should be done. And all the DAM and photo management programs developers would somehow adhere to the standard. And.....  Maybe it's best for users to just continue to mark historical photos as "January 1 or whatever year" and leave well enough alone.

I think that'd be best.  Having this kind of variability with no set standard will lead to problems.

-Kirk

[PeterM]

Thanks to Carl and Kirk for discussing this.

I’m one of the epidemic. My use case is thousands of scanned slides that have the date set to when they were scanned (by a scanning service, so no option to fix the issue at point of scan).

I appreciate without a standard this is difficult although it seems "19860000" is the recommended approach, although not currently possible with the OS date picker?

One thought I had was a ‘zero’ out function - the ability to set the time and date to 00:00:00 01/01/YYYY with YYYYY ideally being user-defined. Perhaps this could be set in preferences or as an option on the Tools -> Adjust Time and Date flyover (is that right term?) Of course, then someone will want MM to also be optionally defined …

I realized an immediate solution is already available in PhotoMechanic using Adjust Time and Date and the Absolute Adjusted Time function. e.g. I can set the absolute date/time to 00:00:00 01/01/1986 and apply that to multiple photos.

David Riecks had suggested putting “Date Created entered is approximate" or equivalent in the description field. I  realize using a variable one could have a pretty coherent description entry e.g. “Date Created entered is approximately {mnn}, {year4}.

[Kirk Baker]

Peter,

I appreciate without a standard this is difficult although it seems "19860000" is the recommended approach, although not currently possible with the OS date picker?

That's correct for both macOS and Windows.

-Kirk