{"thread":{"id":"37835","subject":"Is there way to set git commit --date to be older than 1970 ?","startedAt":"2014-10-29T18:49:19Z","lastAt":"2014-10-30T22:11:53Z","messageCount":9,"participants":["Peter Vojtek","Fredrik Gustafsson","Junio C Hamano","Roberto Eduardo Decurnex Gorosito","Dan Johnson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251183","messageId":"CAOE_JxJp0nA_p_42yOyk_nMjsyMaovj0Fx6AJ5nywiEQfB5XAQ@mail.gmail.com","threadId":"37835","inReplyTo":null,"subject":"Is there way to set git commit --date to be older than 1970 ?","fromName":"Peter Vojtek","fromEmail":"peter.vojtek@gmail.com","sentAt":"2014-10-29T18:49:19Z","receivedAt":"2014-10-29T18:49:19Z","isPatch":false,"sender":{"key":"peter.vojtek@gmail.com","avatar":null},"body":"Hello all,\n\nI am playing with git in slightly unusual manner - e.g., to use git to\nstore history of europe:\n\n$ touch Italy\n$ git add Italy\n$ git commit -m \"add Italy\" --date=\"01/01/1861T01:01:01\" # Italy\ngained sovereignity at year 1861\nfatal: invalid date format: 01/01/1861T01:01:01\n\nIt seems the commit date can be between 1970 and 2100 (on my 32bit\nlinux), however man git (section DATE FORMATS) claims ISO 8601\nstandard is supported. ISO 8601 allows even B.C. dates (via minus\nsign).\n\n\nI understand that this is rather an esoteric use case :)\n\nRegards,\n\nPeter\n"},{"id":"251186","messageId":"20141029191914.GA16599@paksenarrion.iveqy.com","threadId":"37835","inReplyTo":"CAOE_JxJp0nA_p_42yOyk_nMjsyMaovj0Fx6AJ5nywiEQfB5XAQ@mail.gmail.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2014-10-29T19:19:14Z","receivedAt":"2014-10-29T19:19:14Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote:\n> I am playing with git in slightly unusual manner - e.g., to use git to\n> store history of europe:\n\nActually you're the second person I hear that is trying to use git as a\ntimeline of some sort. The previous person had the exact same problem.\nUnfortunately I couldn't find a mailthread about it in the archives.\n\nI'm curious, why did you choose git for this? Maybe this is a use case\nwe should consider?\n\n-- \nMed vänlig hälsning\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"251190","messageId":"xmqqh9ymy8np.fsf@gitster.dls.corp.google.com","threadId":"37835","inReplyTo":"CAOE_JxJp0nA_p_42yOyk_nMjsyMaovj0Fx6AJ5nywiEQfB5XAQ@mail.gmail.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-29T19:31:54Z","receivedAt":"2014-10-29T19:31:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Vojtek writes:\n\n> It seems the commit date can be between 1970 and 2100 (on my 32bit\n> linux),...\n\nThe underlying data representation records time as number of seconds\nsince epoch (1970-01-01). Theoretically the codepaths that read\ndata could consider negative timestamps to represent times before\nthe epoch, but in the context of source code control, negative\nvalues are more likely to be an indication of a bug or a user\nmistake, and I do not think any existing code in Git is prepared to\npass such a timestamp as a sane value---instead they diagnose a\nfailure and die.\n\n> I understand that this is rather an esoteric use case :)\n\nYeah, this is pretty much outside of what we intend to support.\n\nThanks.\n"},{"id":"251191","messageId":"CAOE_JxJ5fUmSTcb4VF+K=y8gej2GqzQJrimt8fVn=gUL6veyqg@mail.gmail.com","threadId":"37835","inReplyTo":"20141029191914.GA16599@paksenarrion.iveqy.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Peter Vojtek","fromEmail":"peter.vojtek@gmail.com","sentAt":"2014-10-29T19:50:16Z","receivedAt":"2014-10-29T19:50:16Z","isPatch":false,"sender":{"key":"peter.vojtek@gmail.com","avatar":null},"body":"thanks for quick response, Fredrik.\n\n> I'm curious, why did you choose git for this? Maybe this is a use case\nwe should consider?\n\nthis is a part of \"thinking out of the box\" mental execise.\n\nWith the advent of many tools to visualize and analyze git\nrepositories, it makes some sense to use the underlying beauty and\npower of git for unusual use cases. Similar evolution happened to\njavascript (originally a simple language to apply form validations on\nbrowser side).\n\nHere are few other use cases which may be fun to realize with git:\n\n- history of political parties in one country. when a party splits\ninto two, we create new branch, and when parties join, we merge\nbranches. branch name = party name. commiter name = party leader.\n\n- how country populations evolve year by year. country is a file,\nbytesize equals to its population.\n\n- track evolution of some political document (e.g., u.s. constitution).\n\n\n\nPeter\n\n\nOn Wed, Oct 29, 2014 at 8:19 PM, Fredrik Gustafsson wrote:\n> On Wed, Oct 29, 2014 at 07:49:19PM +0100, Peter Vojtek wrote:\n>> I am playing with git in slightly unusual manner - e.g., to use git to\n>> store history of europe:\n>\n> Actually you're the second person I hear that is trying to use git as a\n> timeline of some sort. The previous person had the exact same problem.\n> Unfortunately I couldn't find a mailthread about it in the archives.\n>\n> I'm curious, why did you choose git for this? Maybe this is a use case\n> we should consider?\n>\n> --\n> Med vänlig hälsning\n> Fredrik Gustafsson\n>\n> tel: 0733-608274\n> e-post: iveqy@iveqy.com\n"},{"id":"251195","messageId":"CABj5xzcigToDam4JGG9POkaZPh8V=ptEW_F8AO621HA0vCqM8A@mail.gmail.com","threadId":"37835","inReplyTo":"xmqqh9ymy8np.fsf@gitster.dls.corp.google.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Roberto Eduardo Decurnex Gorosito","fromEmail":"decurnex.roberto@gmail.com","sentAt":"2014-10-29T20:03:55Z","receivedAt":"2014-10-29T20:03:55Z","isPatch":false,"sender":{"key":"decurnex.roberto@gmail.com","avatar":"https://gravatar.com/avatar/de236c01ef687a6be0f8dfce2a4f380645a4d9436a700e7e6475c533e50f7c31?d=mp&s=160"},"body":"Peter,\n\nYou should be happy of getting the error message.\n\n Since Git 2 invalid years will default to the current year (keeping\nthe given day and month) without warnings.\n\n--\nRoberto Decurnex\n\nOn Wed, Oct 29, 2014 at 4:31 PM, Junio C Hamano wrote:\n> Peter Vojtek writes:\n>\n>> It seems the commit date can be between 1970 and 2100 (on my 32bit\n>> linux),...\n>\n> The underlying data representation records time as number of seconds\n> since epoch (1970-01-01). Theoretically the codepaths that read\n> data could consider negative timestamps to represent times before\n> the epoch, but in the context of source code control, negative\n> values are more likely to be an indication of a bug or a user\n> mistake, and I do not think any existing code in Git is prepared to\n> pass such a timestamp as a sane value---instead they diagnose a\n> failure and die.\n>\n>> I understand that this is rather an esoteric use case :)\n>\n> Yeah, this is pretty much outside of what we intend to support.\n>\n> Thanks.\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"251222","messageId":"xmqqr3xpwjvj.fsf@gitster.dls.corp.google.com","threadId":"37835","inReplyTo":"CAOE_JxJp0nA_p_42yOyk_nMjsyMaovj0Fx6AJ5nywiEQfB5XAQ@mail.gmail.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-30T17:24:48Z","receivedAt":"2014-10-30T17:24:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Vojtek writes:\n\n> It seems the commit date can be between 1970 and 2100 (on my 32bit\n> linux), however man git (section DATE FORMATS) claims ISO 8601\n> standard is supported.\n\nThe date formats section of \"git log\" only talks about the output\nformat (I do not see in \"man git\" any section about date formats, by\nthe way), once Git understands and records the timestamp in its\ninternal representation (which is \"seconds since the epoch\"; as I\nalready said, theoretically it should be possible to record negative\nnumber of seconds there, the current code does not allow it).\n\nThe documentation may need to be clarified, independent from what\nthe implementation does on the input side. The current text from\n\"git log\" reads like so:\n\n --date=(relative|local|default|iso|iso-strict|rfc|short|raw)\n Only takes effect for dates shown in human-readable\n format, such as when using --pretty. log.date config\n variable sets a default value for the log command’s\n --date option.\n\nThe word \"shown\" is meant to stress that this description is about\noutput side, but apparently it was misread as if somehow a user can\naffect the input by giving --date=iso or something, so perhaps you\nwould want to suggest a better phrasing?\n\nThanks.\n"},{"id":"251240","messageId":"CAPBPrnuxAPmKe_aRb9USh=cOu4jMZaYzOorXC_RJa8b8ROq+iA@mail.gmail.com","threadId":"37835","inReplyTo":"xmqqh9ymy8np.fsf@gitster.dls.corp.google.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Dan Johnson","fromEmail":"computerdruid@gmail.com","sentAt":"2014-10-30T21:08:56Z","receivedAt":"2014-10-30T21:08:56Z","isPatch":false,"sender":{"key":"computerdruid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/34696?v=4"},"body":"On Wed, Oct 29, 2014 at 3:31 PM, Junio C Hamano wrote:\n> Peter Vojtek writes:\n>\n>> It seems the commit date can be between 1970 and 2100 (on my 32bit\n>> linux),...\n>\n> The underlying data representation records time as number of seconds\n> since epoch (1970-01-01). Theoretically the codepaths that read\n> data could consider negative timestamps to represent times before\n> the epoch, but in the context of source code control, negative\n> values are more likely to be an indication of a bug or a user\n> mistake, and I do not think any existing code in Git is prepared to\n> pass such a timestamp as a sane value---instead they diagnose a\n> failure and die.\n\nI remember a pretty old thread found some success storing timestamps this way:\nhttp://comments.gmane.org/gmane.comp.version-control.git/152433\n\n-Dan Johnson\n"},{"id":"251247","messageId":"20141030214852.GB21017@peff.net","threadId":"37835","inReplyTo":"CAPBPrnuxAPmKe_aRb9USh=cOu4jMZaYzOorXC_RJa8b8ROq+iA@mail.gmail.com","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-10-30T21:48:52Z","receivedAt":"2014-10-30T21:48:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 30, 2014 at 05:08:56PM -0400, Dan Johnson wrote:\n\n> > The underlying data representation records time as number of seconds\n> > since epoch (1970-01-01). Theoretically the codepaths that read\n> > data could consider negative timestamps to represent times before\n> > the epoch, but in the context of source code control, negative\n> > values are more likely to be an indication of a bug or a user\n> > mistake, and I do not think any existing code in Git is prepared to\n> > pass such a timestamp as a sane value---instead they diagnose a\n> > failure and die.\n> \n> I remember a pretty old thread found some success storing timestamps this way:\n> http://comments.gmane.org/gmane.comp.version-control.git/152433\n\nA few things have changed since then. Most notably, git is more careful\nabout overflow of \"unsigned long\" when reading in timestamp values. Of\ncourse, we can't do much in the overflow case except assign a sentinel\nvalue. But it at least means that overflowing values all end up as \"Jan\n1 1970\" and not whatever random 32-bit wraparound you happen to get.\n\nBut what _hasn't_ changed is that we still use \"unsigned long\"\ninternally. The fact that the 1787 date in that thread worked at all is\nsomewhat accidental and due to implicit casts between \"unsigned long\"\nand \"time_t\" working. As noted here (and downthread):\n\n http://permalink.gmane.org/gmane.comp.version-control.git/152508\n\nI think it would be a nice project to convert git to consistently use\nsigned 64-bit times internally, and then everything would Just Work\ngoing back to the beginning of history. But the demand for such a\nfeature has been low enough that nobody has really dug in and tried the\nconversion.\n\nWe do also gain some small amount of efficiency by storing commit\ntimestamps as 32-bit values. However, those should always be \"current\"\ntimes anyway. I think we are really talking about author timestamps\nhere (and of course the underlying time-manipulation functions).\n\n-Peff\n"},{"id":"251250","messageId":"xmqqtx2ltdg6.fsf@gitster.dls.corp.google.com","threadId":"37835","inReplyTo":"20141030214852.GB21017@peff.net","subject":"Re: Is there way to set git commit --date to be older than 1970 ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-30T22:11:53Z","receivedAt":"2014-10-30T22:11:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think it would be a nice project to convert git to consistently use\n> signed 64-bit times internally, and then everything would Just Work\n> going back to the beginning of history. But the demand for such a\n> feature has been low enough that nobody has really dug in and tried the\n> conversion.\n>\n> We do also gain some small amount of efficiency by storing commit\n> timestamps as 32-bit values. However, those should always be \"current\"\n> times anyway. I think we are really talking about author timestamps\n> here (and of course the underlying time-manipulation functions).\n\nThere are only three places we store timestamps that matter in the\non-disk representations, so if we were to go 64-bit internally,\nwhich I do not mind at all, we probably should do all three i.e.,\ncommitter, tagger and author dates.\n"}]}