-
Bug
-
Resolution: Answered
-
High (View bug fix roadmap)
-
None
-
None
-
None
Currently the Sprint data is stored in a server timezone specific way, thus backing up the data and restoring it on a server with different timezone results in Sprint start/end/completion dates to be wrong. This can also result in the grey guideline in the Burndown chart appearing incorrectly - it can look like it is "lost". For example it will show purely on the x-axis instead of crossing over from y to x.
Either store the values in UTC millis since epoch or use Date column type (to be validated whether this solves the problem correctly).
Workaround
In order to restore the times back to their last known working form, the below process can be used for the new server:
- Generate an XML backup from the previous server, or obtain the last-known working one and copy it to the new JIRA server.
- Schedule a downtime window.
- Stop the new JIRA server.
- Either:
- Set the JVM timezone argument, e.g.: -Duser.timezone=GMT, as in Setting Timezone in JIRA.
- Change the System Time of the server that the JVM is running on (the JVM will default to that time).
- Start the new JIRA server.
- Import the XML backup from the previous server.
- Test the charts and JIRA.
If the server is unable to be rolled back, the below can be followed, however this is not the recommend method and may cause additional problems due to time inconsistencies.
- Schedule a downtime window.
- Export the XML backup.
- Stop JIRA.
- Either:
- Set the JVM timezone argument, e.g.: -Duser.timezone=GMT, as in Setting Timezone in JIRA.
- Change the System Time of the server that the JVM is running on (the JVM will default to that time).
- Start JIRA.
- Import the XML backup.
- Test the charts and JIRA.
- is caused by
-
JRASERVER-26039 Verify the system timezone when an XML backup is restored
- Closed
- is related to
-
-
- Gathering Impact
-
-
-
- Gathering Impact
-
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
[JSWSERVER-5433] Restoring Sprint data in a different server timezone broken
Brad, did you mean that the XML date info from JIRA has no timezone associated with it, i.e. it is all independent of timezone
We cant fix this bug. JIRA fundamentally does not allow XML data to be timezone independent.
The work around is to look at the XML data, guesstimate the timezone (or talk to the soneone who gave you the XML) and then run the JVM -Duser.timezone = XXX
http://stackoverflow.com/questions/2627992/force-java-timezone-as-gmt-utc
After some more investigation it seems we GH are doding the right thing. Sprint data is indeed strored in as a long in UTC and input/displayed in the users timezone.
However JIRA does NOT encode the timezone in the XML data itself. It does in the database say but not in the XML data. It stores all the times (down to millis) in a text format without TZ infomation
So JIRA exported XML data is inherently not timezone indepenpdent. I spoke to Mark Lassau about this and he said this is not a case they tried to cover. Its been done this way since 2002.
This is something for us and GH support to consider when looking at customers data.
We would need to pass JVM args to put the server into the customers timezone to work as expected.
Alas the XML export does NOT have a easily indentified value that indicates the customers Timezone. We can guess at it but not definitively say what is was.
miruflin : I thought you could reproduce this easy enough?
This was my first attempt at some time based data. Its records it creation dates in the issue summaries
I am worried that this issue is a non issue.
I did some prelim testing and didnt notice anything.
BUT
I am unsure of the exact problem so I am unsure what to fix. Some of the code looks great but perhaps there are other areas that dont work so well but I dont know where they are.
We need to tighten the exact nature of this problem up before we can fix anything
Yes. e.g. see following change entry (which stores the date for one or several change items):
Note the "created" attribute which has a value of "2012-03-08 16:28:50.15". This value isn't UTC but instead jira-system-timezone-at-export specific, so you have to import that data with the same timezone as when exported it to get the same values back. JIRA Agile sprints on the other hand are stored in UTC millis, which doesn't change regardless of import/export timezone.