You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add RevisionTimeStamp as an MSBuild property #1450
It could be useful to know what a commit's timestamp was, in addition to the commit hash/id.
This will allow downstream tooling to use it as appropriate. For example, some basic deployment tools only check file timestamps, so it could be interesting to modify files last write time to the commit timestamp, in order to get deterministic outputs, but still compatible with tools that only use timestamps.
I suggest the timestamp should be in ISO8601 format, possibly with an option to force a specific timezone (commit's original timezone or current machine's local timezone, or UTC)
I like this, however I would suggest the format be in RFC3339 https://www.rfc-editor.org/rfc/rfc3339 instead (not sure if rfc9557 https://www.rfc-editor.org/rfc/rfc9557 should be considered as well?), as the ISO8601 spec costs money to buy and view (CHF 177 / ~USD 190 / ~EUR 170 for Part1: Basic rules ISO 8601-1:2019 and CHF 199 / ~USD 215 / ~EUR 195 for Part2: Extensions ISO 8601-2:2019) which makes it hard for open source usage.
I am trying to prototype this and noticed a few things.
Two timestamps are available for the comit: the author timestamp (timestamp the original author created the changes) and the commit timestamp (the timestamp of the author's changes were applied to the repo by a committer).
The timestamps are included in the commit "object" (as git calls them), and not easily available anywhere else.
There are two implementations of object storage in git these days.
The "loose" format is pretty easy to use. It's a Deflate compressed file stored at .git/objects/{firstTwoDigitsOfHash}/{remainingDigitsOfHash}, where the hash is already available as the RevisionId property.
The "pack" format is much harder to parse, and would probably require somewhat similar complexity as the RefTable reference handling implementation in #1498
Activity
Frulfump commentedon Jul 17, 2025
I like this, however I would suggest the format be in RFC3339 https://www.rfc-editor.org/rfc/rfc3339 instead (not sure if rfc9557 https://www.rfc-editor.org/rfc/rfc9557 should be considered as well?), as the ISO8601 spec costs money to buy and view (CHF 177 / ~USD 190 / ~EUR 170 for Part1: Basic rules ISO 8601-1:2019 and CHF 199 / ~USD 215 / ~EUR 195 for Part2: Extensions ISO 8601-2:2019) which makes it hard for open source usage.
omajid commentedon Nov 30, 2025
I am trying to prototype this and noticed a few things.
Two timestamps are available for the comit: the author timestamp (timestamp the original author created the changes) and the commit timestamp (the timestamp of the author's changes were applied to the repo by a committer).
The timestamps are included in the commit "object" (as git calls them), and not easily available anywhere else.
There are two implementations of object storage in git these days.
The "loose" format is pretty easy to use. It's a Deflate compressed file stored at
.git/objects/{firstTwoDigitsOfHash}/{remainingDigitsOfHash}, where the hash is already available as theRevisionIdproperty.The "pack" format is much harder to parse, and would probably require somewhat similar complexity as the RefTable reference handling implementation in #1498
Add RevisionTimestamp