'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 "prevision" 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