Is there way to set git commit --date to be older than 1970 ?

Hello all,

I am playing with git in slightly unusual manner - e.g., to use git to store history of europe:

$ touch Italy $ git add Italy $ git commit -m "add Italy" --date="01/01/1861T01:01:01" # Italy gained sovereignity at year 1861 fatal: invalid date format: 01/01/1861T01:01:01

It seems the commit date can be between 1970 and 2100 (on my 32bit linux), however man git (section DATE FORMATS) claims ISO 8601 standard is supported. ISO 8601 allows even B.C. dates (via minus sign).

I understand that this is rather an esoteric use case :)

Regards,

Peter

On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote:

Actually you're the second person I hear that is trying to use git as a timeline of some sort. The previous person had the exact same problem. Unfortunately I couldn't find a mailthread about it in the archives.

I'm curious, why did you choose git for this? Maybe this is a use case we should consider?

thanks for quick response, Fredrik.

we should consider?

this is a part of "thinking out of the box" mental execise.

With the advent of many tools to visualize and analyze git repositories, it makes some sense to use the underlying beauty and power of git for unusual use cases. Similar evolution happened to javascript (originally a simple language to apply form validations on browser side).

Here are few other use cases which may be fun to realize with git:

- history of political parties in one country. when a party splits
into two, we create new branch, and when parties join, we merge
branches. branch name = party name. commiter name = party leader.

- how country populations evolve year by year. country is a file,
bytesize equals to its population.

- track evolution of some political document (e.g., u.s. constitution).

Peter

On Wed, Oct 29, 2014 at 8:19 PM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:

Peter Vojtek <peter.vojtek@gmail.com> writes:

The underlying data representation records time as number of seconds since epoch (1970-01-01). Theoretically the codepaths that read data could consider negative timestamps to represent times before the epoch, but in the context of source code control, negative values are more likely to be an indication of a bug or a user mistake, and I do not think any existing code in Git is prepared to pass such a timestamp as a sane value---instead they diagnose a failure and die.

Yeah, this is pretty much outside of what we intend to support.

Thanks.

Peter,

You should be happy of getting the error message.

 Since Git 2 invalid years will default to the current year (keeping
the given day and month) without warnings.

-- Roberto Decurnex

On Wed, Oct 29, 2014 at 4:31 PM, Junio C Hamano <gitster@pobox.com> wrote:

On Wed, Oct 29, 2014 at 3:31 PM, Junio C Hamano <gitster@pobox.com> wrote:

I remember a pretty old thread found some success storing timestamps this way: http://comments.gmane.org/gmane.comp.version-control.git/152433

-Dan Johnson

On Thu, Oct 30, 2014 at 05:08:56PM -0400, Dan Johnson wrote:

A few things have changed since then. Most notably, git is more careful about overflow of "unsigned long" when reading in timestamp values. Of course, we can't do much in the overflow case except assign a sentinel value. But it at least means that overflowing values all end up as "Jan 1 1970" and not whatever random 32-bit wraparound you happen to get.

But what _hasn't_ changed is that we still use "unsigned long" internally. The fact that the 1787 date in that thread worked at all is somewhat accidental and due to implicit casts between "unsigned long" and "time_t" working. As noted here (and downthread):

  http://permalink.gmane.org/gmane.comp.version-control.git/152508

I think it would be a nice project to convert git to consistently use signed 64-bit times internally, and then everything would Just Work going back to the beginning of history. But the demand for such a feature has been low enough that nobody has really dug in and tried the conversion.

We do also gain some small amount of efficiency by storing commit timestamps as 32-bit values. However, those should always be "current" times anyway. I think we are really talking about author timestamps here (and of course the underlying time-manipulation functions).

-Peff

Jeff King <peff@peff.net> writes:

There are only three places we store timestamps that matter in the on-disk representations, so if we were to go 64-bit internally, which I do not mind at all, we probably should do all three i.e., committer, tagger and author dates.

Peter Vojtek <peter.vojtek@gmail.com> writes:

The date formats section of "git log" only talks about the output format (I do not see in "man git" any section about date formats, by the way), once Git understands and records the timestamp in its internal representation (which is "seconds since the epoch"; as I already said, theoretically it should be possible to record negative number of seconds there, the current code does not allow it).

The documentation may need to be clarified, independent from what the implementation does on the input side. The current text from "git log" reads like so:

       --date=(relative|local|default|iso|iso-strict|rfc|short|raw)
           Only takes effect for dates shown in human-readable
           format, such as when using --pretty.  log.date config
           variable sets a default value for the log command’s
           --date option.

The word "shown" is meant to stress that this description is about output side, but apparently it was misread as if somehow a user can affect the input by giving --date=iso or something, so perhaps you would want to suggest a better phrasing?

Thanks.