'Approximate' or 'Circa' Dates

[Mario]

Tip: Users who need to store date information that is uncertain or approximate, the IPTCExt CircaDate may be a way.. This is basically a text field, but it is designated to hold circa dates, without further interpretation.

https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#circa-date-created

for more info. It's not widely used but of course supported by ExifTool and IMatch. You can add this tag to any Metadata Pane layout to view and edit it.

[axel.hennig]

Since I've got some pictures in my database (mostly scanned images taken by my father) for which I do not know the exact date, I would like to start a discussion on how to use this metadata field suggested by Mario.

Things that seem to be important:
- How do we deal with known year, know month, unknown day
- How do we deal with known year, unknow month, known day
- How do we deal with known year, unknow month, unknown day
- How do we deal with unknown year, know month, known day
- How do we deal with unknown year, know month, unknown day
- How do we deal with unknown year, unknow month, known day
- How do we deal with unknown year, unknow month, unknown day
- How do we deal with known data ranges
- How do we deal with images where we can see e.g. that it was taken in summer, but we do not know the year, month or day

I think we should keep in mind that ones we've filled this metadata field how can we search/filter using this field.

At the current time I use categories for the date which looks like:

- year (1)
-- month (2)
--- day (3)
- approximate date (4)
- unknown date (5)

For images I know the exactly date and time these images are in (3). Images I know only year or year and month they are in (1) or (2) and in (4). Images I don't know year, month and day are in (5).

Disadvantage: Things like "summer" or "winter" are not really kept in this system. And if I know the month of an image but not the year then this images would also not really fit into this system.

Happy discussion.

[jch2103]

Tip: Users who need to store date information that is uncertain or approximate, the IPTCExt CircaDate may be a way.. This is basically a text field, but it is designated to hold circa dates, without further interpretation.

https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#circa-date-created

for more info. It's not widely used but of course supported by ExifTool and IMatch. You can add this tag to any Metadata Pane layout to view and edit it.

Thanks. This could be useful for some of my collection of old scanned images. But as alex.henning points out, what's needed is a standard nomenclature for filling in the text field for this tag. Too bad the IPTC.org standard doesn't provide some examples, although these would depend largely on user needs. I need to do some more thinking about this...

[ubacher]

I did a bit of googling:
There is a proposed standard it seems:
http://www.loc.gov/standards/datetime/pre-submission.html

The interesting part is then how to do searches on such dates.........

[Mario]

The interesting part is then how to do searches on such dates.........

It's important that you setup your own controlled vocabulary for your uncertain dates. The IMatch Universal Thesaurus can store this for you. By limiting yourself to a predefined and controlled uncertain date vocabulary you limit the search points to a known set. This helps with searching and also with creating data-driven categories in IMatch...

[jch2103]

Down the rabbit hole!

It appears there's been some more progress on this issue.

1. Some background info from the point of view of a librarian: https://blogs.library.duke.edu/bitstreams/2016/01/22/enjoy-your-metadata-fun-with-date-encoding/ but it's a bit out of date.

2. See also https://www.loc.gov/standards/datetime/ which is more up to date.

3. Ubacher's post links to proposed standards that may be published next year. The second link appears to be the most relevant for our discussion here, but I need to go over it more closely.

[axel.hennig]

I've read "Date and Time Extensions" (part 2, chapter 4) of https://www.loc.gov/standards/datetime/ and I would need some clarification: What is the difference (in meaning) between the character "?" (uncertain) and "~" (approximate)? I do not really know when I would mark a picture with an uncertain date and when with an approximate date. Any help/example is welcome.

[Mario]

Welcome to the marvelous world of metadata, subsection date and time, subsection uncertain & approximate days 

[mastodon]

It would be nice to have a system, that helps to set this pictures with uncertain dates on the timeline of pictures with exact date. And sometime we know the sequence the images, but not the exact date...

[jch2103]

I've read "Date and Time Extensions" (part 2, chapter 4) of https://www.loc.gov/standards/datetime/ and I would need some clarification: What is the difference (in meaning) between the character "?" (uncertain) and "~" (approximate)? I do not really know when I would mark a picture with an uncertain date and when with an approximate date. Any help/example is welcome.

I'm not sure this helps you (or me), but http://www.loc.gov/standards/datetime/pre-submission.html#uncertain provides a few examples:

Examples

1984?
uncertain: possibly the year 1984, but not definitely
2004-06?
2004-06-11?
1984~
"approximately" the year 1984
1984?~
the year is approximately 1984 and even that is uncertain

Also, the same link provides definitions:

Approximate: An estimate whose value is asserted to be possibly correct, and if not, close to correct. (Where 'close to correct' means "close enough, for the application".)
Uncertain: A date or date/time is considered "uncertain" when the process by which it is constructed (e.g. a user or some machine process extracting or converting data or metadata) determines algorithmically or based on rules of operation, that its source is dubious.
Unspecified: The value is unstated. It could be because the date (or part of the date) has not (yet) been assigned (it might be assigned in the future), or because it is classified, or unknown, or for any other reason.

[Mario]

It would be nice to have a system, that helps to set this pictures with uncertain dates on the timeline of pictures with exact date. And sometime we know the sequence the images, but not the exact date...

The timeline uses a year/quarter/month/week/day hierarchy. It depends on the amount of certainty you're dealing with...
More like, January 1920 or more like December 1920? The timeline manages files on the bottom level, which means day - everything rolls up from there.
Just define some anchor points like */1/1 */3/1 */6/1 */9/1 and *12/1 for your uncertain dates in quarter year intervals. Combine that with a value in IPTC CircaDate and you can search for it, filter for it. use it for data-driven categories etc.

[BanjoTom]

I've been doing what  Mario advises for a long time now:

The timeline uses a year/quarter/month/week/day hierarchy. It depends on the amount of certainty you're dealing with...
More like, January 1920 or more like December 1920? The timeline manages files on the bottom level, which means day - everything rolls up from there.
Just define some anchor points like */1/1 */3/1 */6/1 */9/1 and *12/1 for your uncertain dates in quarter year intervals. Combine that with a value in IPTC CircaDate and you can search for it, filter for it. use it for data-driven categories etc.

But I did NOT  know about the IPTC "Circa-date-created" metadata field, so I've been entering the "circa" dates (using the Library of Congress notations for "uncertain" or "approximate" dates) into {File.MD.XMP::dc\coverage\Coverage\0}, which someone had previously suggested as a convenient (but typically unused) field. 

Would there be any advantage now in adding the "circa-date-created" field to my Default metadata list and then moving all the entries from {File.MD.XMP::dc\coverage\Coverage\0} into "Circa-date-created"??

[jch2103]

Would there be any advantage now in adding the "circa-date-created" field to my Default metadata list and then moving all the entries from {File.MD.XMP::dc\coverage\Coverage\0} into "Circa-date-created"??

There may not be any direct advantage for us as individuals, but it makes sense to use standards where they exist. Could be a benefit later.

I've also been following the advice re using first day of the year/month/etc. to indicate approximate dates; I'll need to try modifying my custom metadata layout to add the "circa-date-created" field.

[Mario]

As long as you don't exchange files with third parties, you can do whatever is convenient for you.
But copying your existing data to the circa field using  a metadata template is easy to do. You can even transform data if needed that way.

[janb83]

Just a word of warning to anyone stumbling upon this topic when researching circa dates:

While it is true that ExifTools offers this field, it is important to note that there are actually two similar fields. The one that Mario linked to, which is part of an Artwork struct within XMP, and the "default"/"simple" one ExifTool offers.

Linked by Mario: {File.MD.XMP::iptcExt\ArtworkOrObjectAOCircaDateCreated\ArtworkCircaDateCreated\0}
Simple one: {File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0}

Please note that ONLY the one linked by Mario is actually part of the IPTC photo metadata standard, the other one is not. ExifTool implemented it but took it from the IPTC video metadata hub(!). Personally, I thus use both tags to avoid any future issues.

[Damit]

It would be nice to have a system, that helps to set this pictures with uncertain dates on the timeline of pictures with exact date. And sometime we know the sequence the images, but not the exact date...

The timeline uses a year/quarter/month/week/day hierarchy. It depends on the amount of certainty you're dealing with...
More like, January 1920 or more like December 1920? The timeline manages files on the bottom level, which means day - everything rolls up from there.
Just define some anchor points like */1/1 */3/1 */6/1 */9/1 and *12/1 for your uncertain dates in quarter year intervals. Combine that with a value in IPTC CircaDate and you can search for it, filter for it. use it for data-driven categories etc.

I know this is old, but I have been working on a system for this problem for a while and am buttoning it up.  I am wondering why Mario is proposing 2 dates to use for winter, perhaps he will weigh in.  I am weighing the pros and cons of using two dates for winter (12/01 and 1/01 vs just using 12/01). The Winter Year spans two calendar years, creating ambiguity when assigning a proxy date for filename labeling. A single proxy date is required for sorting consistency.
Originally I was using this scheme:
Seasonal, Quarterly Estimation:For items where the month or day are unknown, but the season can be estimated, use:
`01-01` for Winter (Close to 12/21-12/22 (Winter Solstice))
`04-01` for Spring (Close to 3/20-3/21 (Spring Equinox))3
`07-01` for Summer (Close to 6/20-6/21 (Summer Solstice) 3
`10-01` for Fall (Close to 9/22-9/23 (Fall Equinox)) 3
`12-01` for Late Winter (Default for general Winter) (Close to 12-21 or 22 (Winter Solstice))

But I am strongly thinking of just using YYYY-12-01 because it:
• Aligns with intuitive naming—"Winter 2010" corresponds to 2010, not 2011
• Maintains chronological sorting within the labeled year
• Avoids overused boundary dates (e.g., 12-31, 01-01)
• Approximates meteorological early winter
• Simplifies rule application (vs. dual anchor dates)

Limitations include temporal drift for late-winter images (e.g., actual capture in Jan–Feb),but I am considering a fallback option using YYYY+1-01-01 to reflect the likely capture period while still preserving filename integrity. More precise ranges (e.g., "2010-12-01 to 2011-03-01") will be recorded in metadata Circa.date.Created
Does anyone have an opinion on this or perhaps suggestions for other alternatives?
Any input is appreciated!

[Mario]

A simple pattern usually does it. It all depends.
For most projects I've worked on a "precision" of 1/2 or 1/4 year was enough.

[PandDLong]

I was using a coded format for dates to handle uncertain/approximate dates - very similar to the examples listed here and the examples found elsewhere on the web. 
I abandoned it. The main reasons:

• If it was too simple (eg. a few special dates per year), then I lost any known details when looking at the timeline view or without hunting further in the metadata
• A complex code allowing more detail, seemed to need a "decoder ring" (especially after a pause in photo work)

• The timeline in IMatch was crowded around the "code" dates
• I use the date as the prefix for the file name so the files sort in timeline order which is helpful for others when I share the files.  Crowding around a few dates was not helpful.

I wanted to avoid a complex code (especially as I needed to explain it to other family members), I wanted the timeline view to be as reasonably accurate as possible and I wanted to quickly handle any situation without too much thinking.

So what do I do?

1. I use the CircaDate tag as a "displayable" date which has the information that is known - eg. 1962, 1962 Summer, 1962 August, 1960-64 Summer, 1961/62 Winter, etc.   If a file does not have a value for the CircaDate then the date on the file is known and exact.

2. The date on the file is a somewhat random date that "fits".  The following guidelines apply:

• Any known sequences of files are given dates so they sort on the timeline correctly
• Photos from the same date or the same event get the same date.  Any known sequence within the date is handled through setting the time

• I avoid the same date for files that don't fit the guideline for same date (this does require changing the dates sometimes to avoid conflicts)
• For files with a wide range (eg. 1962 or 1960-64 Summer), I assign a date so they appear in the timeline at or near the beginning of the possibility 

3. For the filename, if the file is an approximate date (CircaDate has a value) then I add an 'a' after the date - the one piece of coding that i explain to my extended family (eg. 1962-08-10a  vs. 1962-08-10)

4. Whenever I add captions to photos or use design & print, I use the CircaDate if it exists.

A downside is that if I want to find files from 1963 I would easily miss ones that start outside the range (eg. 1960-64).  This has not been an issue yet, if it becomes one, I am confident there are ways to solve for that by populating other tags with the date range and using the datecomp function.


I have scanned, cataloged and shared a few hundred photos (and videos) this way and so far it seems to work well.  I am much happier with this than when I had used the coded date on a couple hundred photos earlier - I may need to go back and change all of those ... sigh!

I hope that is helpful and good food for thought.

Michael

[sinus]

I wanted to avoid a complex code (especially as I needed to explain it to other family members), I wanted the timeline view to be as reasonably accurate as possible and I wanted to quickly handle any situation without too much thinking.

Michael

I think, that is basically, what I can agree.

And also, what Mario wrote, is true for me:

A simple pattern usually does it. It all depends.

Basically I have files, where not only the date is unsure.
For specialy older files some "facts" I do also not know the (exact) location and for some family photos I do even not know some persons on the photo.

I think, we have to find a way, what can be very personal, that you can find these photos and that you can see, that some data is unsure.
With regard to the date I add simply a (good) guessed date in my normal filenaming-system.
Hence it is integrated into my timeline and will be sorted fine.

But of course it can be on the wrong sorted place, because the date can be wrong.
This does not matter for me, because I know these files. But additionally I can add a special "mark" for me.
And this can be very personal. For some people this can be an easy collection like red pin.
Or a tag, what is used only for such files.

And we can even add for such files a special icon in the file window (custom layout).

For me this is like Michael pointed out, this should not be too complex, because some family members cannot follow, we can forget it, or it is too much effort.

Hence there is for me not "the" solution, but individual ones (except you work in a historical environment with other people).

[Damit]

Hence there is for me not "the" solution, but individual ones (except you work in a historical environment with other people).

Thank you Markus, as always, for your input. It is appreciated. Yes, it can be very personal.  I think this scheme is mostly pertinent for scanned images, or those with corrupted time//date information.

I hope that is helpful and good food for thought.

Thank you Michael. It most certainly is. I have been working on this for a few months off and on while working on other projects. I think my system may address your concerns as I will have a method for "translating" file name info into corresponding EDTF format values in the CircaDateCreated field (this has not been developed yet but will use renamer and other IMatch tools to make this possible).

While I understand your issue with placeholder dates, sometimes you just have no idea and there needs to be a place for those pictures. You can always try to guess a date in my system, but if you don't want or feel comfortable doing so, you have a place. I have attached the Date Block portion of my file naming scheme here so you can get an idea of what I am doing up to now, in case it may help others. It is a work in progress,though. There are mentions of reference sections not included and so forth, but it still may be useful. Once I have finalized this will post any revisions in case they may be of use.

[Date Block Info

[hluxem]

I have attached the Date Block portion of my file naming scheme

Nice write up, I have been using a date and time named based file naming scheme for years. For scanned pictures or digitized movie files I run into too many problems keeping everything up to date and abandoned the scheme. For many files the date changed over time as I gathered more information. Every time I changed the estimated date & time, the file name changed and that impacted backups and created more "opportunities" to mess up. For me it worked best to just use a reel or film-based system which I marked the originals with as well. Date and time are maintained in the appropriate meta data field. That sorts them correctly in the timeline which is important to me.

Heiner

[Mario]

In my experience, schemes too complex rot over time.

Details are forgotten, no longer maintained properly, date portions kept in file names become out of sync with metadata, etc. All bad.

Using the standard XMP timestamps to record an approximate timestamp down to either half-year (6/1, 12/1) or quarter (1/1, 4/1, ...) stores a good enough timestamp where it belongs - in metadata.

This makes the Timeline, events, sorting, searching, and other time-based features in IMatch work as you would expect.

As mentioned above, the Circa Date Created is a text tag and can contain anything that works for you.From "About first half of 1879" to "Either August or September 1911" to "Unknown, used best approximate", all options are valid.

If you are consistent with this, you can use a non-empty Circa Date tag as an automatic indicator for files with uncertain dates. Two flies with one stone.

You can also use a category or collection ti mark files with uncertain dates, of course.

But I always prefer things to be automatic and no-brainers. The less chance I have to mess up or forget, the better. If Circa Date is used, IMatch can automatically take care of this for you.

Additionally, you can create a formula-based category (@MetadataTag) that includes all files with a non-empty Circa Date tag. Alternatively, you might build a data-driven category based on this tag to group images with the same value together.

IMatch stores XMP timestamps and Circa Date tags in your images or sidecars, ensuring they persist forever and remain accessible by all XMP-enabled software (which "supports" the Circa Date tag).
Unfortunately, even professional software often supports only a tiny subset of XMP—typically what they prefer to use. Ideally, such tools would follow the XMP standard and maintain unused or non visible tags.

If you must cater to the lowest common denominator and support applications or services with minimal metadata awareness (where CircaDate is not an option), you can achieve similar results using any XMP tag that isn't used for other purposes.

If you absolutely need this type of information in file names, use the Renamer.

You can rename files with the Renamer to include the XMP timestamp and Circa Date—even in specifically formatted forms, thanks to IMatch variables.

The beauty of this approach is that you can just run the Renamer again when you update the XMP timestamp and/or Circa Date after finding a "better" date. This ensures consistency and automates the process.

[hamishr]

My approach to dating digitized photographs:
1. I use Date Subject Created to provide my best guess of the exact date the photograph was taken. If I only know the nearest year, I enter the date as the midpoint of the year - so for 1976, I would enter it as 1976:06:30. If I know the date to the nearest month, then I enter the date as the midpoint of the month (the 15th), so for May 1976, I would enter it as 1976:05:15.
2. In the Description field, I enter any annotations on the photograph in quotation marks, e.g. "England, May 1976". If I have had to estimate the date without any annotations, I write down my thought processes. e.g. Date uncertain: estimated to probable year - 1976, based on models of cars on the road. 

I could be more consistent in how I record my degree of uncertainty and it might be useful to have a field to record degree of uncertainty.

In museums collection databases (I used to work at the South African Museum), a verbatim date field is used, where the date is recorded exactly as it is on the collection label - this would be equivalent to the circa date field Mario mentions. So, the Verbatim Date shows how the date has been interpreted in the date fields. Dates are entered as ranges with separate fields for days, months and years, which provides for most date variations. So "May 1976" would be entered as 01 05 1976 [to] 30 05 1976.

[Mario]

I recommend using CircaDate which was designed to hold the data you mention.
And an approx calendar date to place the images on the IMatch timeline.

[Mario]

I decided to write a new knowledge-base blog entry for uncertain dates. Good for users, good for the Google bot:

Lost in Time? Tackling Uncertain Dates with Old Photos and Digital Asset Management

Please help me out and produce some "traffic" by reading it. Google likes that, even if I don't use Google tracking on my site.

[PaulS]

Nice article.

Is this a typo "typically DD.MM.YYYY HH:MM:SS  (as required by XMP date and time tags and ExifTool)."

IIRC it is YYYY.MM.DD HH:MM:SS

[mastodon]

How can I make a sign in the Viewer, that an image has a value at "CircaDateCreated", so it is an approximate date?

[Mario]

How can I make a sign in the Viewer, that an image has a value at "CircaDateCreated", so it is an approximate date?

You cannot make any signs in the Viewer. You can mark images in the File Window with a text tag or an icon using the normal techniques and e.g. this variable: {File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated|hasvalue:Yes;No}

[Mario]

IIRC it is YYYY.MM.DD HH:MM:SS

Both is correct (depending on locale and situation). But I've swapped it to YYYY.* for clarity now.

[Mario]

I've enhanced the article by adding information about how you can utilize the IMatch Thesaurus to ensure consistency for CircaDateCreated entries. Many users don't know that the Thesaurus can manage data for all tags, not just keywords.

I've also updated the help topic about working with uncertain dates a bit for the next help release.

[fisketjon]

How can I set the File header in the File Window to display CircaDateCreated if present, but DateCreated (Create Date) otherwise?

[Mario]

Use custom template header in your FW layout and use variable and hasvalue: hasvalue:Text
This allows you to check if tag A has a value and if so, emit it, else emit tag B.

Let us know when you need help with setting up the variable or the custom template (there are many examples in the help).

[PandDLong]

How can I set the File header in the File Window to display CircaDateCreated if present, but DateCreated (Create Date) otherwise?

This is the variable expression I use to do that.

{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|default:{File.MD.datecreated|format:YYYY-MMM-DD}}


I use this same expresssion in a few places - a selection of file window layouts, batch processor presets to add captions and in design & print.


Michael

[fisketjon]

Related question:

How(where) would you add information on the relative sequence of images within the same Circadate?

e.g. scanning negatives from the same film roll you have the frame numbers 

[PandDLong]

That is entirely up to you.  How you do it is based on what you are trying to achieve.

I use datecreated to maintain chronological sequence.  Of course, for digitally captured photos, this is natural.  For scanned, while I populate Circadate as needed, I also assign datecreated dates & times to manage sequence within a set of photos (eg. a roll) as well as across scanned photos from different sources so the IMatch Timeline looks reasonable.   But that's me.

If you use datecreated, you can use TimeWiz to set incremental times across a set of photos which makes it easier.


Some alternatives that come to mind:

1. If you always scan in the right order than createdate will maintain this sequence for you.

2. If you want the sequence in the Circadate, it is a free-text field so you can put the frame number or a sequence number into the text as a suffix.

3. If the frame number is important to you, you can capture it an unused XMP tag (there are a lot of them).  I don't believe there is any metadata standard or common practice for this piece of data (and I have looked).


As a side note, I do capture frame numbers for slides in an XMP tag.  I do this as I have thousands of old slides and many are jumbled, capturing the frame number (and some details of the slide mount) helps me match them up into their original sequences within IMatch.

In my journey of using IMatch as I have added more and different types of content (I am essentially a family archivist), I have found my solutions to some challenges (like chronology) have changed over time.  IMatch has made it easy to switch my solution and retrofit it to everything in my database.

I suggest doing something that captures what you want at the time of importing into IMatch when that metadata is easily available to you so it is in the database - you can move it around later.


I hope this is useful food for thought.  Good luck

Michael

[Tveloso]

I have been using an IMatch Attribute to indicate what portion of the date I've assigned to old scans, has been guessed at.  This is a "date mask" which I included in the FileWindow Thumbnails, below the assigned date.  For example, here, I am reasonably sure that the year was 1935:

    You cannot view this attachment.

...but here, I'm not sure of even the year, in the date I've assigned:

    You cannot view this attachment.

Although that gives a visual indication of the date's uncertainty, it's not really that much information.  Inspired by this discussion, and Mario's article, I decided to start using the CircaDate tag, and to "convert" my "date mask" to be part of the value I would store there.

As Mario advises in the article:

If you decide to use the "CircaDateCreated" tag to record information for images with uncertain dates, consistency is crucial.

Avoid variations like "Summer 1923" and "Around Summer 1923". Using consistent phrasing to describe approximate dates makes it easier to group images with similar date approximations using data-driven categories.

...I wanted my CircaDate values to follow a consistent structure (and I also wanted to include that "date mask" in the structure).  So I established the following 17 values in the Thesaurus:

     You cannot view this attachment.

...(and here in a mono-spaced font, which hopefully shows the structure a little better):

       ....+....1....+....2....
     1 Spring YYYY ~~/~~/YYYY
     2 Summer YYYY ~~/~~/YYYY
     3 Autumn YYYY ~~/~~/YYYY
     4 Winter YYYY ~~/~~/YYYY
     5 Jan. YYYY   01/~~/YYYY
     6 Feb. YYYY   02/~~/YYYY
     7 Mar. YYYY   03/~~/YYYY
     8 Apr. YYYY   04/~~/YYYY
     9 May. YYYY   05/~~/YYYY
    10 Jun. YYYY   06/~~/YYYY
    11 Jul. YYYY   07/~~/YYYY
    12 Aug. YYYY   08/~~/YYYY
    13 Sep. YYYY   09/~~/YYYY
    14 Oct. YYYY   10/~~/YYYY
    15 Nov. YYYY   11/~~/YYYY
    16 Dec. YYYY   12/~~/YYYY
    17 YYYY - YYYY ~~/~~/~~~~

I then created a Metadata Template to "post" the year portion of the assigned date to the appropriate spots in the CircaDate string:

    You cannot view this attachment.

The Variable in that ScreenShot is the following:

Code Select Expand

{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|substr:0,{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|find:YYYY}}{File.MD.XMP::photoshop\DateCreated\DateCreated\0|format:YYYY}{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|substr:{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|find:YYYY;math:add,4},{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|findreverse:YYYY;math:sub,{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|find:YYYY;math:add,4}}}{File.MD.XMP::photoshop\DateCreated\DateCreated\0|format:YYYY}{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|substr:{File.MD.XMP::iptcExt\CircaDateCreated\CircaDateCreated\0|findreverse:YYYY;math:add,4}}

So for a given file, I would select the appropriate "template string" from the Thesaurus, and the CircaDate tag would initially get a value  something like this:

    Summer YYYY ~~/~~/YYYY

Then the MD Template would update it to look like this (populating both the "real CircaDate" value, and my "date mask"):

    Summer 1935 ~~/~~/1935

Then, as described in Mario's article, I could create a DataDriven Category to identify the Files that have an uncertain date  (in my case it would pull the first 11 Bytes of the CircaDate values), and my FileWindow Layout could be changed to use the last 10 Bytes of that same tag (instead of the Attribute I'm using now).

I have tested this, and it seems to be working well.  But as I write this, I find myself still mulling over some aspects of it.  In particular, whether or not I should really include that "date mask" in the Circa Date, or if I should just carry on with the Attribute for that particular thing. 

I'm definitely going to make use of CircaDate, and the scheme discussed here, but then I wonder if I should really be "mixing two things" there.  First I think: if that "mask" is in the CircaDate tag, then I can pull it from the Thesaurus, and it will be consistent, and maintained in one place.  But then I think: if I kept the "date mask" either in the existing Attribute, or in a separate tag, then I could refer to the Attribute (or Tag) directly, in both the FileWindow and the CircaDate DD Category, without the need to use a variable to do substringing.

Also, for most of my older scans, that "date mask" is going to be the "~~/~~/~~~~", so the CircaDate value will usually be of the form YYYY - YYYY ~~/~~/~~~~, which does not provide for the estimation of a Season or Month.  So I might need to essentially double the number of "Template String" values I keep in the Thesaurus (and push that "date mask" over to position 20):

       ....+....1....+....2....+....3
     1 Spring YYYY        ~~/~~/YYYY
     2 Summer YYYY        ~~/~~/YYYY
    ...
    15 Nov. YYYY          11/~~/YYYY
    16 Dec. YYYY          12/~~/YYYY
    17 YYYY - YYYY        ~~/~~/~~~~
    18 YYYY - YYYY Spring ~~/~~/~~~~
    19 YYYY - YYYY Summer ~~/~~/~~~~
    20 YYYY - YYYY Autumn ~~/~~/~~~~
    21 YYYY - YYYY Winter ~~/~~/~~~~
    22 YYYY - YYYY Jan.   ~~/~~/~~~~
    ...
    33 YYYY - YYYY Dec.   ~~/~~/~~~~

So I guess I'm still toying with how to go about doing this.  But the general idea, of pulling a "template value" from the Thesaurus, and then using a MD Template to "post" a Year value to it, will help me keep CircaDate values consistent.

[Tveloso]

As I was working on the CircaDate scheme discussed in my previous post, it occurred to me to try having AutoTagger help with estimating dates for my old scans.  I created a separate config to populate only Description:

    You cannot view this attachment.

...using the following prompt:

[[-c-]] Estimate the Year and if possible the month this photo was taken, based on features such as clothing any people are wearing, any automobiles shown, and any other features that might suggest a time period.  Describe the reasoning behind the Year and Month estimate given.

...and was pretty impressed with the results. 

For example, for this photo (which is not one of mine, so I have no real insight into what a good estimate would be):

    You cannot view this attachment.

...it initially estimated a 15-year range (1905-1920):

Estimated Year: 1905-1920
Reasoning: The sepia tone suggests an early photographic print, typical of the late 1800s to early 1900s. The clothing style worn by the individual standing near the bridge is consistent with early 20th-century fashion (high-waisted skirt or dress). The lack of automobiles and the overall rustic scene further indicate a time before widespread automobile use, placing it likely between 1905 and 1920. It's difficult to ascertain a specific month but based on the foliage and lighting conditions it could be late spring or early summer (May-June).

I then ran it again, adding some details to the placeholder - to also hopefully correct the gender error the AI had made.  This time, it echoed back the entire prompt at the beginning of its response, reduced the estimate to a 10-year range (1910-1920), and was now willing to guess at the season of the year:

The Jackson Covered Bridge in Jackson, New Hampshire was built in 1876. The two men in this photo appear to be wearing knickers and bow ties. Estimate the Year and if possible the month this photo was taken, based on features such as clothing any people are wearing, any automobiles shown, and any other features that might suggest a time period.

**Estimated Year:** 1910-1920

**Estimated Month:** Likely August or September

**Reasoning:** The men's attire - knickers (plus fours) and bow ties - were commonly worn by gentlemen during the early 20th century, particularly in rural areas. This style peaked in popularity around the 1910s-1920s.  The sepia tone and photographic quality are consistent with early photography from that era. The lack of visible automobiles further supports a date before widespread car ownership.  Based on the foliage and apparent sunlight conditions, the photo was likely taken during late summer or early fall (August/September), when outdoor activities would have been common in New Hampshire.

Pretty cool!  I think I'll go ahead and add that estimate to the CircaDate.

[Mario]

Good idea 

Remember that these AIs have been trained on tens of billions of images. And if you (AI) have seen one million or maybe even a hundred million images for each year since photography was invented, you probably have a much larger area of reference to use when dating photos...

From people's clothes to hair and beard styles to buildings, cars, period appliances or even trees or landmarks shown, AI's may have access to data that allows them to date a photo much better than we can do.

A prompt like

"Date this photo taken in the United States of America to the best of your abilities and respond with a short phrase like: 'Approximately 1910 to 1920' or 'this photo was taken between 1930 and 1940'".

may work well for almost all cases.
When you store the results in "CircaDate" and make a data-driven category based on this tag, you'll have a great base to work from.

Even if the AI is wrong. it is often wrong - in my experience - consistently wrong in the same way for the same type of motive. Which puts all of these "wrong" images in the same "bucket" (aka category).
And this allows a you and me to process and date the images a lot quicker.

Note: If you find a prompt that works well, please help out others and post it, maybe with some examples (and the AI and model used) in this board: https://www.photools.com/community/index.php/board,149.0.html

This may help other users, and me, a lot.

[PandDLong]

As I was working on the CircaDate scheme discussed in my previous post, it occurred to me to try having AutoTagger help with estimating dates for my old scans.

That is a great idea!    I haven't found a good use case for AutoTagger for myself yet, but this looks to be it.

Thanks for the inspiration.

Michael