Github -> JIRA shows incorrect commit times

Jason Nichols July 19, 2012

I've got Github->Jira integration nearly perfect, except for one annoying issue. When I make a commit via Github, it shows up in the JIRA immediately as "7 hours ago"

Checking the Git log, I see:

commit 1abc40ab89cef19a4a379c87cd129a648f924fc4

Author: Jason Nichols <jason@xxxxx.com>

Date: Fri Jul 20 09:56:14 2012 -0400

Testing timezone funkyness, TEST-2

This is correct, I made the commit about 5 minutes ago, and my current GMT offset is -4. Why would JIRA show this as having happened 7 hours ago?

Edit: A bit more information. Looking at the RSS feed for the JIRA dashboard, the commit above has the following field:

<published>2012-07-20T06:56:14.000Z</published>

<updated>2012-07-20T06:56:14.000Z</updated>

This is incorrect! The update happened at 13:56 Zulu. It happened at 9:56 local time. Is the hosted JIRA ignoring the timezone offset from the Git commit?

Lastly, I believe that the hosted JIRA is located in California, but am not positive. That would account for the extra 3 hour difference (for a total of 7 hours as shown above) since the server is hosted 3 hours behind my local time.

6 answers

1 accepted

1 vote
Answer accepted
Michael Knight
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 15, 2012

This is a known issue with the DVCS Connector:

I don't have any information on a timeline for a fix yet though. Please feel free to vote/comment/watch the issue as you see fit.

3 votes
MartinM November 4, 2012

Hi All

JIRA DVCS Connector is using EGit library to communicate with GitHub. It turns out that there was some incompatibility between EGit and GitHub API in the providing and parsing the timestamps. After discussion with Github support they changed the timestamp format in GitHub API and EGit is now parsing timestamps correctly. All new commits should have correct time from now on. If you want to fix the timestamps of existing commits you need to resynchronize your repository from Manage DVCS Accounts page. (Administration > Source Control > DVCS Accounts)

Please let us know if the problem persists/reappears.

Cheers
Martin

Rafael Bodill November 6, 2012

Thanks Martin! It works great now. So what did Github change in their API ? It looked like they used PST instead of UTC...

MartinM November 6, 2012

The GitHub API documentation is mentioning the ISO 8601 format 'YYYY-MM-DDTHH:MM:SSZ' for timestamps. In fact ISO standard itself is defining a range of various allowed syntaxes for timestamps and the one mentioned is just on of them. GitHub REST API was returning PST time indeed. It was ISO 8601 valid format but not the same as described in the documentation (e.g. 2012-02-06T04:15:27-08:00).

Rafael Bodill November 6, 2012

I knew it! :) Thanks for sorting this out with GitHub Martin! Much obliged.

0 votes
Rafael Bodill August 14, 2012

It's aweful. Commit dates are completely wrong and confusing.

0 votes
Alexandru Verdes August 14, 2012

Has anyone found a solution to this? The problem is really annoying.

0 votes
Rafael Bodill July 30, 2012

We have the same issue with the DVCS plugin, JIRA and Github. Every new commit shows up immediately as "7 hours ago"... I think JIRA is misinterpreting Github's time zone.

Our time zone is GMT+3, this an example of how a commit looks like:

  • In local repo: 19:15
  • In Github: 9:15
  • In JIRA: 12:15

Github uses the PST (Pacific time zone), and NOT UTC !!!

Please fix it guys! Commit timestamps are extremely important!

0 votes
Rafael Bodill July 30, 2012

We have the same issue with the DVCS plugin, JIRA and Github. Every new commit shows up immediately as "7 hours ago"... I think JIRA is misinterpreting Github's time zone. Github uses PST, and not UTC !!

Our time zone is GMT+3, this an example of how a commit looks like:

  • In local repo: 19:15
  • In Github: 9:15
  • In JIRA: 12:15

Github uses the PST (Pacific time zone), and NOT UTC !!!

Please fix it guys! Commit timestamps are extremely important!

Suggest an answer

Log in or Sign up to answer