You can't.
Well, you might be able to, but there are too many complex issues.
Specifically, each Git object is stored in a database of all objects, indexed by hash-ID keys. Some objects are loose: stored as separate files. Such a file is zlib-deflated. Any zlib-inflator can read this file and turn the compressed data into readable, useful data, and what you will see if you do this with a commit hash ID is the actual commit object content:
$ git cat-file -p HEAD | sed 's/@/ /'
tree 1fd4a47af4942cbdee0bdcb4375612ab521a4a51
parent 5571d085b3c9c2aa9470a10bcf2b8518d3e4ec99
author Junio C Hamano <gitster pobox.com> 1531941857 -0700
committer Junio C Hamano <gitster pobox.com> 1531941857 -0700
Third batch for 2.19 cycle
Signed-off-by: Junio C Hamano <gitster pobox.com>
(Here I have used a Git command to do the job, which violates your rule.) The dates are those two time stamps on the author
and committer
lines. You can simply decode them however you like, though remember to use the time zone offset, -0700
here, as well. (The internal content is prefixed with a header, in this case commit <size>\0
, as all Git objects have headers.)
But loose is not the only way objects get stored. Once an object has been lying around loose for a while, Git will eventually pack the object into a pack file. The format of pack files is quite complicated. It is documented—see the Git technical documentation file—but it's subject to change and not worth coding when git cat-file -p
already does all the work for you.
So, just use a Git command. This does mean you need Git installed, but you probably need that anyway.