Dating an Entry: First Appearance and Other Dates

"When did it come out?" is one of the simplest questions you can ask about a product, and one of the hardest to answer. The announcement, the first demo, the first download, the 1.0 release and the company's founding all have dates, and they can differ by years. A catalogue that files under the wrong one, or does not say which, quickly becomes unreliable.

This guide is about dates in a catalogue of debuts: the kinds there are, which one a debut directory should use, how to write dates so they cannot be misread and how to handle evidence and disagreement. It is a small subject, and an important one, because the date is often the first thing a reader checks.

The many dates of a product

Think of the life of a product as a timeline with several marks.

Conception. When the idea began. Rarely documented.

Founding. When the company or team was formed.

First private use. When testers first saw it.

Announcement. When the product was first publicly mentioned.

First public appearance. When people outside the team could first see or use it.

Release. When it was made generally available.

Major versions. Version one, version two.

Relaunch. A significant new introduction of an existing product.

Renaming. When it changed names.

Retirement. When it stopped.

Record dates. When the catalogue entry was created and last checked.

A catalogue must choose what its main date means and record the others if it can.

The date a debut directory files under

A debut directory is about firsts, so its main date is the date of first public appearance: the earliest moment at which the public could see, or use, the product. This differs from the announcement, which might be a promise of something that does not yet exist, and from the release, which might come much later.

Edge cases need rules.

• A public demo before release. Counts as the first public appearance.
• A waitlist page with no product. Does not, though it may record the announcement.
• A private beta by invitation. Not public. A public beta is.
• A product shown at an event. Counts if the public could see it.
• A product launched in one country first. The earliest date anywhere counts, noting the place.
• A relaunch. Does not change the debut date. Record the relaunch separately.

State these rules on the directory's pages, and apply them uniformly.

Write dates so they cannot be misread

The notation for dates differs across the world. "03/04/2024" is the third of April in much of Europe and the fourth of March in the United States. A catalogue that reaches readers across countries cannot afford the ambiguity.

The international standard for the exchange of date and time information writes the year first, then the month, then the day, with leading zeros: 2024-04-03. This form has several advantages.

• It is unambiguous.
• It sorts correctly as text.
• It is readable by machines.
• It extends naturally: year only, year and month, full date.

For human readers, writing the month in words is equally clear: 3 April 2024.

Choose one form for the directory and use it everywhere. Machine-readable versions can sit behind the display.

Partial dates and approximate dates

Not every product has a precise date on record.

• Year only: "2019". Honest and useful.
• Year and month: "2019-06". Better.
• Full date: "2019-06-14".
• Approximate: "circa 2019", "early 2019", with the reason.

Never invent precision. A guessed day is worse than an honest year. Record how certain the date is: exact, month only, year only, approximate.

Time zones

For a product that appeared on the web, the same moment is a different date in different places. A launch at 11 pm on the fourth of March in New York is the fifth of March in London. For most catalogue purposes the day is enough, but where it matters, record the time zone. The standard format includes a way to express it.

Keep a consistent rule: date as given by the maker in their local time, or in a common reference time. Say which.

Evidence

A date in a catalogue is a claim. It needs support.

Good evidence includes:

• A dated public post or announcement.
• An archived copy of the page. Services such as the Wayback Machine capture snapshots of web pages with dates, giving independent proof that a page existed on a certain day.
• Release notes or a changelog with dates.
• A store listing showing the first release date.
• A press or community mention with a visible date.
• A repository history, showing the first public commit or release.
• A domain registration date, which proves little by itself but can help.

Weaker evidence includes memory, undated pages and unverified claims.

Record the source of the date alongside it. Metadata standards often include elements for the date and for the source of a resource, and for relations between records. A catalogue entry that says "first public appearance: 2019-06-14; source: archived announcement page" is far more trustworthy than a bare date.

When sources disagree

They often do.

• A maker remembers June; an archive shows May.
• A press article gives the release date, not the first demo.
• Two sources use different time zones.

A sensible procedure:

1. List the candidate dates and their sources.
2. Prefer primary, contemporaneous evidence over later memory.
3. Prefer independent evidence over self-reported.
4. Check what each date actually measures. The disagreement may be between date types, not within one.
5. Choose the best-supported date, and record the discrepancy in a note.
6. Leave a route to correction. If new evidence appears, update.

Do not hide the disagreement. A note saying "The maker gives June; an archived page dated May shows the product already available. May is used." is honest and helpful.

Handling claims of "first"

Makers like to be first. Catalogues should be careful.

• "First product of its kind" is a claim that needs evidence and a precise definition of the kind.
• "First public appearance" concerns this product, not others.

A catalogue records dates. It does not need to adjudicate who invented a category. If asked, point to the evidence and let readers decide. Advertising and consumer rules in many places expect superlative claims such as "first" to be supportable, so a careful directory avoids repeating them uncritically.

What makers should do

• Know your own dates and keep evidence.
• Archive important pages when you publish them.
• State your first public appearance clearly on your page.
• Distinguish announcement from availability.
• Give dates in an unambiguous form.
• Tell the catalogue if a date is wrong, with evidence.
• Keep release notes dated.

What editors should do

• Define the main date and publish the definition.
• Record other dates in separate fields.
• Show the date type next to every date.
• Show the source and the date last checked.
• Use an unambiguous format.
• Support partial dates.
• Keep a history of changes to dates.
• Provide a correction route.

What readers should do

• Check which date it is.
• Check the source, if shown.
• Compare with another source for anything that matters.
• Note the last-checked date.
• Cite the date type when you quote it.

A short worked example

A product's entry shows: Announced 2018-11-02. First public appearance 2019-03-18 (public beta). Released 2019-09-30 (version 1.0). Founded 2017. Renamed 2021-05-01 (formerly another name). Last checked 2024-01-12. Source for first public appearance: archived beta page dated 2019-03-18.

A reader sees five dates, knows what each means and can verify the main one. A journalist writing that the product "launched in 2019" is right in two senses and can specify which. A competitor claiming to have debuted earlier can check the evidence. The directory has served as a record, not just a list.

On this site

The launches page shows debut dates with their types, the search page lets you find entries by year and the submit page is where makers record their dates and sources. The contact page reaches a person if a date is wrong.

A short checklist for makers submitting a date

Before you submit a date, check four things. Which kind of date is this: announcement, first public appearance or release? What is your evidence, and can you link it? Is the format unambiguous? Do you know whether it is exact, month only or year only? Writing these answers in the submission note takes a minute and saves the editors an email. If you are unsure, say so, and give your best evidence. Editors would much rather receive an honest "probably early 2019, here is the earliest page I can find" than a confident day that cannot be supported.

The short version

Products have many dates: announced, first public, released, founded, renamed and more. A debut directory files under the date of first public appearance, defines its edge cases, records other dates separately, writes them year first or with the month in words, supports partial dates, cites evidence and notes disagreements. Makers should keep evidence and archive pages; readers should check which date they are reading. A date is a claim, and a good catalogue shows its working.