Can you describe where you're seeing the time stamp as "-1"? Is it in the change logs, the summary of changes with each build, through an API call, or some other location?

Can you provide a series of steps that will allow others to see the same failure you're seeing?

Does your time zone or locale affect the behavior?

The plugin needs to support git versions older than git 2. Many users are running older platforms (CentOS 6 - git 1.7.1, CentOS 7 - git 1.8.3.1, Debian 6 - git 1.7.2.5, Debian 7 - git 1.7.10.4, Ubuntu 14.04 - git 1.9.1, Windows - msysgit 1.9.5). I'm willing to consider inserting git version specific code, but it is more painful to maintain, more difficult to test, and more likely to break.

When that -1 is reported, do you also get a stack trace in the Jenkins log file on the server? An as yet unreleased change to the date parsing (for Java 6 compatibility) might help with this case, if a stack trace is being placed into the log file when the request is made.

If you're not running Java 6, then that is not likely the problem.

We are seeing them in all changelog through api calls. The timestamp in summary of changes with each build is correct.

It's internal API call so I am not sure how to let you replicate this. But the problem believe to be https://github.com/jenkinsci/git-client-plugin/blob/de49c9bf21f560ac3851c4f7ea3a3597a114ac8e/src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java#L704 not using %aI

Unfortunately, we can't abandon support for git versions prior to git 2, so we can't switch to the argument form you listed.

Can you provide a small test program which shows the problem, possibly using the Cloudbees Jenkins server so that you don't need to host a public server?

I have the same problem for all builds timestamp.png.

-bash-4.2# git --version
git version 2.4.0

Jenkins ver. 1.609.3

GIT client plugin
Shared library plugin for other Git related Jenkins plugins.
1.19.0

Git plugin
This plugin integrates Git with Jenkins.
2.4.0

Slava Kopchenin thanks for the picture. It showed that the API call is a public API that is easily accessible. That makes it easier to write a test for this bug.

For example, I see a problem timestamp in the json response when I request http://localhost:8085/view/git-client/job/git-client-multi-master/242/api/json but not when I request http://localhost:8085/view/git-client/job/git-client-multi-master/244/api/json. In my use case, it doesn't seem to be an "every build" occurrence, but it happens on at least some of my cases.

Is your Jenkins server running with Java 6, or with a later version of Java?

"for all builds" I mean in my case...

I logged the hudson.plugins.git.GitChangeSet#parseCommit and the jenkins.log has the following output:

commit 302548f75c3eb6fa1db83634e4061d0ded416e5a
tree e1bd430d3f45b7aae54a3061b7895ee1858ec1f8
parent c74f084d8f9bc9e52f0b3fe9175ad27c39947a73
author Viacheslav Kopchenin <vkopchenin@odin.com> 2015-10-06 19:29:47 +0300
committer Viacheslav Kopchenin <vkopchenin@odin.com> 2015-10-06 19:29:47 +0300

    pom.xml

:100644 100644 bb32d78c69a7bf79849217bc02b1ba2c870a5a66 343a844ad90466d8e829896c1827ca7511d0d1ef M	modules/platform/pom.xml

But, when I changed(ai->aI, ci->cI):

-            public static final String RAW = "commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b";
+            public static final String RAW = "commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %aI%ncommitter %cN <%cE> %cI%n%n%w(76,4,4)%s%n%n%b";

The output is:

commit 841fd27f1a0ef11a1696e3a5cb6eced316761ee3
tree 369d49618e2752d809ee8807149c402485b8e15b
parent b5ad39f1d9c338cb76b2851d8b2ebcef7d59484e
author Viacheslav Kopchenin <vkopchenin@odin.com> 2015-10-06T20:09:18+03:00
committer Viacheslav Kopchenin <vkopchenin@odin.com> 2015-10-06T20:09:18+03:00

    pom.xml

:100644 100644 5868c1b334fdea0d25b21705604e9e1d6f3243b8 56f50739924afe9d151a3c89aa7ace332e55b044 M	modules/platform/pom.xml

Slava Kopchenin thanks for the output. Unfortunately, as noted in the earlier comment, the

%cI

argument is not workable in the git client plugin because the plugin must support git versions prior to git 2.

We can't abandon support for Red Hat 5, Red Hat 6, Debian 6, and several other working environments which provide git versions prior to git 2.

Your output is a good source to use to write a test to show the failure and then you could submit a pull request with the test and with code changes to resolve the failure. Even if all you do is write a test to show the failure and submit that as a pull request, that will help move towards an eventual fix for the bug.

I checked the %cI argument and it is definitely understood by git 2.6.0, but is not understood by git 2.1.4 (Ubuntu 14.04), git 1.9.1 (Debian 8), or git 1.7.1 (CentOS 6.7). Your sample is enough that I was able to create a failing test case to show the problem.

I submitted pull request 355 asking for a review of my proposed fix.

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/GitChangeSet.java
src/test/java/hudson/plugins/git/GitChangeSetBasicTest.java
src/test/java/hudson/plugins/git/GitChangeSetEmptyTest.java
src/test/java/hudson/plugins/git/GitChangeSetEuroTest.java
src/test/java/hudson/plugins/git/GitChangeSetSimpleTest.java
src/test/java/hudson/plugins/git/GitChangeSetTimestampTest.java
src/test/java/hudson/plugins/git/GitChangeSetUtil.java
http://jenkins-ci.org/commit/git-plugin/b84c7c9dcea3a30a87eadb7d20c8be773cab46e3
Log:
[Fix JENKINS-30073] changeset time shouldn't be -1

The changeset time parsing implemented in an earlier commit did not
account for the most common format of the "nearly ISO" date format
generated by the "+%ci" format argument.

The fully ISO 8601 compliant date format argument ( +%cI ) is not
available in all the git versions supported by the plugin, so the plugin
continues to use the nearly ISO 8601 compliant format ( +%ci ), then
transforms it into an ISO 8601 format when the timestamp is requested.

For example, git 2.1.4 as shipped with Debian 8 does not recognize +%cI
for date formatting. Git 2.6.0 version does recognizes +%cI.

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/GitChangeSet.java
src/test/java/hudson/plugins/git/GitChangeSetBasicTest.java
src/test/java/hudson/plugins/git/GitChangeSetEmptyTest.java
src/test/java/hudson/plugins/git/GitChangeSetEuroTest.java
src/test/java/hudson/plugins/git/GitChangeSetPluginHistoryTest.java
src/test/java/hudson/plugins/git/GitChangeSetSimpleTest.java
src/test/java/hudson/plugins/git/GitChangeSetTimestampTest.java
src/test/java/hudson/plugins/git/GitChangeSetUtil.java
http://jenkins-ci.org/commit/git-plugin/1eda4923300eac714b2fe2027ce7d89d844e32cb
Log:
Merge pull request #358 from MarkEWaite/master-JENKINS-30073-timestamp-parsing

[Fix JENKINS-30073] API timestamp return correct value

Compare: https://github.com/jenkinsci/git-plugin/compare/4979aced9de7...1eda4923300e

Change has merged to the master branch, including tests. The tests show that at least two git older versions (1.7.1 as shipped with CentOS 6 and 1.7.2.5 as shipped with Debian 6) which are known to work in some use cases will show some failures reporting the timestamp of certain commits. The root problem seems to be in the

git whatchanged

command on those git versions. Newer git versions don't have the problem. Refer to the git plugin source code for more details.

Will be included in git plugin 2.4.1.

Included in git plugin 2.4.1 released 26 Dec 2015