An old Git commit date is not a public launch date

A repository contains a commit dated March 2024. Someone presents it as proof that a feature was publicly available then. The date is worth recording, but the conclusion needs another source: a timestamp stored in a Git commit does not, by itself, establish when that commit became public.

Start by reading both date fields and identifying the event you need to date. Creating a local commit, sending it to a remote repository and making its contents publicly accessible are different events.

Read the author date and committer date together

A commit records a project snapshot and related metadata in Git. It can be created on one computer without publishing the project. Each commit stores an author date and a committer date. Treat them as named fields, not interchangeable labels for “published”. Git’s commit documentation explicitly allows author and committer dates to be supplied through environment variables. Their presence is therefore not an independent clock witness.

If you already have a trusted local copy, this read-only command displays the complete commit identifier and both dates. Replace COMMIT_ID with the identifier you are checking:

git show -s --format="commit=%H%nauthor=%aI%ncommitter=%cI" COMMIT_ID

In the official git show documentation, %aI and %cI mean strict ISO 8601 author and committer dates. The -s option suppresses the patch. You are inspecting metadata; you do not need to run the project’s application or install its dependencies.

If you are using only a web view, preserve the commit’s exact link and the field labels shown there. GitHub documents that the profile view uses the author date while a repository view uses the commit date. Those display rules can explain an apparent disagreement; they do not establish a first-publication event. See GitHub’s contribution reference.

A local test with deliberately old dates

This is a synthetic exercise performed locally on 1 November 2026. We created a new repository containing one harmless text file and deliberately supplied two older dates. There was no remote and no network publication. Inspecting the resulting commit returned:

author=2024-03-10T09:00:00Z
committer=2024-03-12T10:00:00Z

The output was checked in Git 2.54.0 for Windows. It demonstrates that the inspected object can contain those dates even though the exercise repository was created much later. It is not a test of GitHub’s interface or evidence that a real developer manipulated anything.

Now consider the claim “this code was publicly available by 10 March 2024”. The synthetic author field is insufficient: the exercise had never been published. The committer field does not repair the argument. It too was supplied as metadata. The appropriate finding is that two date values were observed, while public availability remains unestablished.

Different dates are not automatically suspicious. History-editing workflows can produce differences, as GitHub’s documentation explains. Conversely, equal dates would not turn the record into proof of publication. The question is what independently connects the exact content to public access at the claimed time.

A push is a separate event

The Git push manual describes sending necessary data and updating references in a remote repository. A commit can exist before that happens. Sending an existing commit does not make its stored author timestamp a receipt for the transfer; a remote repository can also be private.

For a public-availability claim, look for a dated public capture containing the relevant file or an independently preserved public reference that identifies the exact content. Examine what the evidence actually exposes. A page naming the project may not contain the feature; an old issue now visible on a public repository does not, merely from its creation date, prove that the repository was public then.

Keep a clear distinction between “visible in this capture by this date” and “first published on this date”. The first statement may be supportable without proving the second. The website-history guide covers evaluating dated web observations.

Normalize time zones before declaring a conflict

A separate synthetic example: 2024-03-10T12:30:00+03:30 and 2024-03-10T09:00:00Z describe the same instant. The three-and-a-half-hour difference is the offset, not a second event. Preserve the original strings and a normalized UTC value. Do not compare a relative label such as “two years ago” with a precise timestamp as though they had the same resolution.

Record the review in five short lines:

• The exact timing claim and the feature or file it concerns.
• The repository and full commit identifier inspected.
• Both date fields, including their offsets.
• The independent public observation, with its source and date, if one exists.
• The supported time bound and the part still unknown.

If the actual dispute is who created the feature, use the repository contribution guide; a chronology check does not settle authorship. For the timing question, place the five lines in the OSINT report template. “The commit records a March date; public availability by March is not established by the material reviewed” is a complete and useful result when that is what the evidence supports.