{"thread":{"id":"42350","subject":"[Bug] git-log prints wrong unixtime with --date=format:%s","startedAt":"2016-05-16T23:33:33Z","lastAt":"2016-05-19T15:41:39Z","messageCount":12,"participants":["Michael Heerdegen","Jeff King","Junio C Hamano","Randall S. Becker"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"286741","messageId":"87vb2d37ea.fsf@web.de","threadId":"42350","inReplyTo":null,"subject":"[Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Michael Heerdegen","fromEmail":"michael_heerdegen@web.de","sentAt":"2016-05-16T23:33:33Z","receivedAt":"2016-05-16T23:33:33Z","isPatch":false,"sender":{"key":"michael_heerdegen@web.de","avatar":"https://gravatar.com/avatar/1b8a6d9962edbc31c5821513ec1abb3d6ce709fa23ffa76b1714b5aa8134bcd6?d=mp&s=160"},"body":"Hello,\n\nthe command\n\n   git log --pretty=format:%ad --date=format:%s\n\ndisplays wrong unixtime values; apparently how much the printed value\ndiffers from the expected value depends on the system's time zone and\nwhether daylight savings time is enabled or not.\n\nHere is a reproducible recipe compiled by Yuri Khan who helped me\nlocalizing the problem and whom I CC'd:\n\n0. Versions\n\n    $ git --version\n    git version 2.8.2\n\n    $ dpkg -l tzdata | tail -1\n    ii  tzdata  2016d-0ubuntu0.16.04 all  time zone and\ndaylight-saving time data\n\n1. Initialize an empty Git repository:\n\n    $ git init test\n    $ cd test\n\n2. Make a commit, using the Europe/Berlin time zone:\n\n    $ TZ=Europe/Berlin git commit -m 'test' --allow-empty\n\n3. Examine the timestamp recorded in the commit object:\n\n    $ git cat-file -p HEAD | grep author\n    author Yuri Khan <yurivkhan@gmail.com> 1463260938 +0200\n\n4. Check that it corresponds to the current time:\n\n    $ date +%s\n    1463260977\n\n5. Try to get the commit date in the unixtime format:\n\n    $ TZ=Europe/Berlin git log --pretty=format:%ad --date=format:%s -1\n\nExpected result: 1463260938 (same as recorded in the commit object).\nObserved result: 1463264538 (3600s = one hour ahead).\n\nFor lulz, use another time zone:\n\n    $ TZ=Asia/Novosibirsk git log --pretty=format:%ad --date=format:%s -1\n\nExpected result: 1463260938 (unixtime is always UTC and should not\ndepend on TZ).\nObserved result: 1463246538 (-14400s = 4 hours behind).\n\nNot even specifying the UTC time zone helps:\n\n    $ TZ=UTC git log --pretty=format:%ad --date=format:%s -1\n\nExpected result: still 1463260938.\nObserved result: 1463268138 (7200s = 2 hours ahead).\n\n\nFWIW, personally I have not bound the TZ environment variable, my time\nzone is constantly that of Berlin, currently CEST.\n\nMany thanks in advance,\n\n\nMichael.\n"},{"id":"286803","messageId":"8760ucoaus.fsf@web.de","threadId":"42350","inReplyTo":"87vb2d37ea.fsf@web.de","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Michael Heerdegen","fromEmail":"michael_heerdegen@web.de","sentAt":"2016-05-17T17:25:31Z","receivedAt":"2016-05-17T17:25:31Z","isPatch":false,"sender":{"key":"michael_heerdegen@web.de","avatar":"https://gravatar.com/avatar/1b8a6d9962edbc31c5821513ec1abb3d6ce709fa23ffa76b1714b5aa8134bcd6?d=mp&s=160"},"body":"Michael Heerdegen <michael_heerdegen@web.de> writes:\n\n> the command\n>\n>    git log --pretty=format:%ad --date=format:%s\n>\n> displays wrong unixtime values; apparently how much the printed value\n> differs from the expected value depends on the system's time zone and\n> whether daylight savings time is enabled or not.\n\nTwo more comments:\n\n  - --date=raw seems to work correctly (though the doc tells it would\n    also use \"%s\").\n\n  - When specifying versions like @{N hours}, the result seems to differ\n    (by one hour?) from what I expect, too.\n\n\nThanks,\n\nMichael.\n"},{"id":"286847","messageId":"20160518004008.GA20007@sigill.intra.peff.net","threadId":"42350","inReplyTo":"8760ucoaus.fsf@web.de","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-18T00:40:08Z","receivedAt":"2016-05-18T00:40:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 17, 2016 at 07:25:31PM +0200, Michael Heerdegen wrote:\n\n> Michael Heerdegen <michael_heerdegen@web.de> writes:\n> \n> > the command\n> >\n> >    git log --pretty=format:%ad --date=format:%s\n> >\n> > displays wrong unixtime values; apparently how much the printed value\n> > differs from the expected value depends on the system's time zone and\n> > whether daylight savings time is enabled or not.\n> \n> Two more comments:\n> \n>   - --date=raw seems to work correctly (though the doc tells it would\n>     also use \"%s\").\n\nI think the doc is misleading there. None of the date formats except the\nrecently added \"--date=format\" use strftime at all.\n\nThe problem is almost certainly some mismatch between git's idea of the\ntimezone and what we are feeding to strftime. I'm not sure if it will be\nsolvable, though. strftime() takes a \"struct tm\", which has no timezone\nfield. We feed it a \"struct tm\" either in the author's timezone or in\nthe user's timezone (if \"format-local\" was used). We could feed it in\nUTC, but I'm not sure that solves the problem, and it probably makes new\nones.\n\nIn your examples, you showed that setting $TZ changes the epoch time\nstrftime gives us. Which probably means that it is guessing the fed\n\"struct tm\" is in the local timezone, which would still be wrong.\n\nAnd even if that did work, feeding it UTC means that all of the other\nnon-%s values would be in UTC, not in the author's or user's timezone.\n\nSo we need some way to tell strftime \"...and by the way, this is the\ntimezone for the value we are currently feeding you.\" There isn't a slot\nin \"struct tm\" for that, but I think maybe you can hack around it by\nsetting the global \"timezone\" variable (and then restoring it\nafterwards).\n\n>   - When specifying versions like @{N hours}, the result seems to differ\n>     (by one hour?) from what I expect, too.\n\nThis is probably a totally separate issue, as it would not be using\nstrftime (or IIRC, any of the standard time functions at all). Do you\nhave a detailed example that shows the problem?\n\n-Peff\n"},{"id":"286848","messageId":"20160518005824.GA7120@sigill.intra.peff.net","threadId":"42350","inReplyTo":"20160518004008.GA20007@sigill.intra.peff.net","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-18T00:58:25Z","receivedAt":"2016-05-18T00:58:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 17, 2016 at 08:40:08PM -0400, Jeff King wrote:\n\n> So we need some way to tell strftime \"...and by the way, this is the\n> timezone for the value we are currently feeding you.\" There isn't a slot\n> in \"struct tm\" for that, but I think maybe you can hack around it by\n> setting the global \"timezone\" variable (and then restoring it\n> afterwards).\n\nI tried a few obvious things, but couldn't make anything work. Setting\n\"timezone\" manually seems to do nothing. It's supposed to be set by\nputting the right thing in $TZ and then calling tzset(). So I tried\nmunging $TZ to something like \"+0200\". It did have _some_ effect, but I\ncouldn't get it to behave correctly in all situations. And using \"%z\"\nand \"%Z\" always just gives GMT.\n\nSo I dunno. Perhaps there is some way to coax sane behavior out of\nstrftime, but I could not figure it out. Suggestions welcome.\n\n-Peff\n"},{"id":"286891","messageId":"xmqqvb2bs5f5.fsf@gitster.mtv.corp.google.com","threadId":"42350","inReplyTo":"20160518005824.GA7120@sigill.intra.peff.net","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-18T16:21:34Z","receivedAt":"2016-05-18T16:21:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I tried a few obvious things, but couldn't make anything work. Setting\n> \"timezone\" manually seems to do nothing. It's supposed to be set by\n> putting the right thing in $TZ and then calling tzset(). So I tried\n> munging $TZ to something like \"+0200\". It did have _some_ effect, but I\n\nWouldn't that be more like \"UTC+0200\"?\n\nIn any case, I do not think anybody wants to do tzset() on each and\nevery commit while running \"git log\".  Can we declare \"format:<strftime>\"\nwill always use the local timezone, or something?\n"},{"id":"286894","messageId":"005a01d1b124$976dceb0$c6496c10$@nexbridge.com","threadId":"42350","inReplyTo":"xmqqvb2bs5f5.fsf@gitster.mtv.corp.google.com","subject":"RE: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2016-05-18T16:44:43Z","receivedAt":"2016-05-18T16:44:43Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 18, 2016 12:22 PM Jeff King wrote:\n> > I tried a few obvious things, but couldn't make anything work. Setting\n> > \"timezone\" manually seems to do nothing. It's supposed to be set by\n> > putting the right thing in $TZ and then calling tzset(). So I tried\n> > munging $TZ to something like \"+0200\". It did have _some_ effect, but\n> > I\n> \n> Wouldn't that be more like \"UTC+0200\"?\n> \n> In any case, I do not think anybody wants to do tzset() on each and every\n> commit while running \"git log\".  Can we declare \"format:<strftime>\"\n> will always use the local timezone, or something?\n\nOff the wall: Dealing in a dispersed team sharing a server that has a\ntimezone local for only two of the members, git log messes with me also from\na TZ POV. I would like to suggest a more general solution, like configuring\nmy own TZ in ~/.gitconfig which would potentially allow an override on the\ncommand line. Would user.timezone be helpful in this situation and if set,\ncall setenv(\"TZ=...\")? It's not an issue when I'm local, but if I touch a\nclone on the server, even I get confused around DST changes in October ;).\n\nCheers,\nRandall\n\n-- Brief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)/NonStop(211288444200000000)\n-- In my real life, I talk too much.\n"},{"id":"286904","messageId":"20160518174919.GA5796@sigill.intra.peff.net","threadId":"42350","inReplyTo":"xmqqvb2bs5f5.fsf@gitster.mtv.corp.google.com","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-18T17:49:19Z","receivedAt":"2016-05-18T17:49:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 18, 2016 at 09:21:34AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > I tried a few obvious things, but couldn't make anything work. Setting\n> > \"timezone\" manually seems to do nothing. It's supposed to be set by\n> > putting the right thing in $TZ and then calling tzset(). So I tried\n> > munging $TZ to something like \"+0200\". It did have _some_ effect, but I\n> \n> Wouldn't that be more like \"UTC+0200\"?\n\nMaybe. I tried several different things, and couldn't make it work\nsensibly with any of them. My test case is basically:\n\n  git log --format=\"%ad%n%at\" --date=format:'%H:%M %z (%Z)%n%s'\n\nWhich should give three lines: the human-readable time and date,\nstrftime's epoch time, and git's epoch time. And the following\nconditions should be met:\n\n  1. The human-readable time is in the author's timezone (or the user's\n     if you use format-local).\n\n  2. The zone offset and name in the first line matches the time we\n     show.\n\n  3. The epoch times for the latter lines should match.\n\nWe currently get (1) right (which is good, because it is IMHO the most\nimportant). I haven't been able to get (2) to change at all, no matter\nwhat I do. And (3) is the subject of debate here; I suspect I could make\nit work at the cost of breaking (1) by giving a \"struct tm\" that is in\nUTC.\n\n> In any case, I do not think anybody wants to do tzset() on each and\n> every commit while running \"git log\".  Can we declare \"format:<strftime>\"\n> will always use the local timezone, or something?\n\nI think that is basically the case already. It is in the author's\ntimezone or in the viewing user's timezone (as reported by localtime()),\nand everything seems to work except the %z zone information and the %s\nformat.\n\nFor a raw \"%s\" date-format, my suggestion is: don't. It is redundant\nwith --date=raw.\n\nI'd love to make %z work, but I have no idea how.\n\nSo I guess we could list those in BUGS in one of the manpages.\n\n-Peff\n"},{"id":"286905","messageId":"20160518175127.GB5796@sigill.intra.peff.net","threadId":"42350","inReplyTo":"005a01d1b124$976dceb0$c6496c10$@nexbridge.com","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-18T17:51:27Z","receivedAt":"2016-05-18T17:51:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 18, 2016 at 12:44:43PM -0400, Randall S. Becker wrote:\n\n> Off the wall: Dealing in a dispersed team sharing a server that has a\n> timezone local for only two of the members, git log messes with me also from\n> a TZ POV. I would like to suggest a more general solution, like configuring\n> my own TZ in ~/.gitconfig which would potentially allow an override on the\n> command line. Would user.timezone be helpful in this situation and if set,\n> call setenv(\"TZ=...\")? It's not an issue when I'm local, but if I touch a\n> clone on the server, even I get confused around DST changes in October ;).\n\nI'm not sure I understand the problem. If you don't like the local\ntimezone used on the server, why don't you set TZ there? What does\nit buy us to introduce a git config option to do the same thing?\n\n-Peff\n"},{"id":"286946","messageId":"87vb2b560k.fsf@web.de","threadId":"42350","inReplyTo":"20160518004008.GA20007@sigill.intra.peff.net","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Michael Heerdegen","fromEmail":"michael_heerdegen@web.de","sentAt":"2016-05-18T22:57:15Z","receivedAt":"2016-05-18T22:57:15Z","isPatch":false,"sender":{"key":"michael_heerdegen@web.de","avatar":"https://gravatar.com/avatar/1b8a6d9962edbc31c5821513ec1abb3d6ce709fa23ffa76b1714b5aa8134bcd6?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> This is probably a totally separate issue, as it would not be using\n> strftime (or IIRC, any of the standard time functions at all). Do you\n> have a detailed example that shows the problem?\n\nOk, this was probably false alarm.  Magit (An Emacs Git front end) shows\nrounded duration values (rounded hours in my case) in its log views, I\nthink I just got confused because of this.  In my tests now, the results\nwere as expected.\n\n\nThanks,\n\nMichael.\n"},{"id":"286949","messageId":"87r3cz55mv.fsf@web.de","threadId":"42350","inReplyTo":"20160518174919.GA5796@sigill.intra.peff.net","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Michael Heerdegen","fromEmail":"michael_heerdegen@web.de","sentAt":"2016-05-18T23:05:28Z","receivedAt":"2016-05-18T23:05:28Z","isPatch":false,"sender":{"key":"michael_heerdegen@web.de","avatar":"https://gravatar.com/avatar/1b8a6d9962edbc31c5821513ec1abb3d6ce709fa23ffa76b1714b5aa8134bcd6?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n>   3. The epoch times for the latter lines should match.\n\nFWIW, I think the epoch time is the most practical way to transfer the\ntime of a commit into a different program.  When this program wants to\ndo it's own date arithmetic with it, unix time is just nice (no time\nformat parsing needed).\n\nThat's why it would be good if the unix time values could be relied on.\n\nConclusion: in addition to 3., I wished both epoch times were also\ncorrect per se.\n\n\nRegards,\n\nMichael.\n"},{"id":"286960","messageId":"20160519015455.GB24225@sigill.intra.peff.net","threadId":"42350","inReplyTo":"87r3cz55mv.fsf@web.de","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-19T01:54:55Z","receivedAt":"2016-05-19T01:54:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 19, 2016 at 01:05:28AM +0200, Michael Heerdegen wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> >   3. The epoch times for the latter lines should match.\n> \n> FWIW, I think the epoch time is the most practical way to transfer the\n> time of a commit into a different program.  When this program wants to\n> do it's own date arithmetic with it, unix time is just nice (no time\n> format parsing needed).\n> \n> That's why it would be good if the unix time values could be relied on.\n\nOh, I agree that unix times are handy. I just think that \"use %at in the\npretty-format, instead of %ad and then %s in the date-format\" is not\nsuch a bad workaround.\n\n> Conclusion: in addition to 3., I wished both epoch times were also\n> correct per se.\n\nThe %at one should be correct, no? If it's not, that's a separate bug.\n\n-Peff\n"},{"id":"286991","messageId":"878tz6m4wc.fsf@web.de","threadId":"42350","inReplyTo":"20160519015455.GB24225@sigill.intra.peff.net","subject":"Re: [Bug] git-log prints wrong unixtime with --date=format:%s","fromName":"Michael Heerdegen","fromEmail":"michael_heerdegen@web.de","sentAt":"2016-05-19T15:41:39Z","receivedAt":"2016-05-19T15:41:39Z","isPatch":false,"sender":{"key":"michael_heerdegen@web.de","avatar":"https://gravatar.com/avatar/1b8a6d9962edbc31c5821513ec1abb3d6ce709fa23ffa76b1714b5aa8134bcd6?d=mp&s=160"},"body":"Jeff King <peff@peff.net> writes:\n\n> Oh, I agree that unix times are handy. I just think that \"use %at in the\n> pretty-format, instead of %ad and then %s in the date-format\" is not\n> such a bad workaround.\n\nI had missed %at (and %ct).  Yes, works perfectly - thanks for the hint.\n\n\nRegards,\n\nMichael.\n"}]}