Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-12554

Incorrect timestamps after re-importing a backup on a machine with a different timezone

XMLWordPrintable

      NOTE: This bug report is for JIRA Software Server. Using JIRA Software Cloud? See the corresponding bug report.

      When exporting data on a machine with timezone UTC+10 and importing it again on a machine with timezone UTC+2 all timestamps are off by 8 hours (note: they will show e.g. 4:30 pm on both machines regardless of the timezone).
      This causes issues with JIRA Agile data which is stored as unix timestamps and does not contain a timestamp by definition, those are imported correctly with the right offset.

      Steps to reproduce:

      1. Set timezone to UTC+10
      2. Export data
      3. Stop JIRA
      4. Set timezone to UTC+2
      5. Start JIRA
      6. Import data

      Symptoms

      • Agile charts do not list the correct issues, and the graphs are also incorrect.
      • Issue dates such as created, updated are also incorrect.

            [JSWSERVER-12554] Incorrect timestamps after re-importing a backup on a machine with a different timezone

            Fabiano Martins (Inactive) added a comment -

            https://getsupport.atlassian.com/browse/GHS-211234

            Fabiano Martins (Inactive) added a comment - https://getsupport.atlassian.com/browse/GHS-211234

            Matt Doar added a comment -

            Yup, Jira dates in the database have no timezone associated with them. The way Jira decides on the timezone is through a chain. The machine timezone, then the timezone that Java uses, then the default Jira timezone, then the user's choice of timezone. If you take data from a Jira instance that was using a different timezone, you may be able to adjust it but the adjustment always ends up being annoying later on. We ended up biting the bullet and changing to UTC and dealing with the wrong dates. This is a good reason why many companies run all their machines in UTC

            Matt Doar added a comment - Yup, Jira dates in the database have no timezone associated with them. The way Jira decides on the timezone is through a chain. The machine timezone, then the timezone that Java uses, then the default Jira timezone, then the user's choice of timezone. If you take data from a Jira instance that was using a different timezone, you may be able to adjust it but the adjustment always ends up being annoying later on. We ended up biting the bullet and changing to UTC and dealing with the wrong dates. This is a good reason why many companies run all their machines in UTC

            Yevgen Lasman added a comment -

            Here is my experience with this issue.

            For example, in a Cloud instance I have and issue ABC-123. Using REST API call /rest/api/2/issue/ABC-123 I can get issue id id: "12345" and created: "2017-12-08T10:19:02.460-0800" date. Now when I create backup out of this Cloud instance, relevant record in the generated entities.xml file is

            <Issue id="12345" number="4501" project="10920" reporter="XXXXXXXXXXXXx" assignee="XXXXXXXXXXXXX" creator="XXXXXXXXXXXX" type="6" summary="XXXXXXXXXXXXXXXXXXXXXXXXXx" priority="1" status="10906" created="2017-12-08 18:19:02.46" updated="2018-01-09 12:23:52.679" votes="0" watches="5" workflowId="94980">

            which seems to be brought to the UTC time (so the issue creation time is 2017-12-08 18:19:02.46 UTC).

            However when I restore this backup on a server, restore module takes UTC date and applies current user's time zone instead of applying server's one. In my case, my user's time zone is UTC+2 and one I restore this backup, I'm getting 2017-12-08T18:19:02.460+0200 for the restored issue.

            Yevgen Lasman added a comment - Here is my experience with this issue. For example, in a Cloud instance I have and issue ABC-123. Using REST API call /rest/api/2/issue/ABC-123 I can get issue id id: "12345" and created: "2017-12-08T10:19:02.460-0800" date. Now when I create backup out of this Cloud instance, relevant record in the generated entities.xml file is <Issue id= "12345" number= "4501" project= "10920" reporter= "XXXXXXXXXXXXx" assignee= "XXXXXXXXXXXXX" creator= "XXXXXXXXXXXX" type= "6" summary= "XXXXXXXXXXXXXXXXXXXXXXXXXx" priority= "1" status= "10906" created= "2017-12-08 18:19:02.46" updated= "2018-01-09 12:23:52.679" votes= "0" watches= "5" workflowId= "94980" > which seems to be brought to the UTC time (so the issue creation time is 2017-12-08 18:19:02.46 UTC ). However when I restore this backup on a server, restore module takes UTC date and applies current user's time zone instead of applying server's one. In my case, my user's time zone is UTC+2 and one I restore this backup, I'm getting 2017-12-08T18:19:02.460+0200 for the restored issue.

              Unassigned Unassigned
              wkritzinger Wolfgang Kritzinger
              Affected customers:
              13 This affects my team
              Watchers:
              24 Start watching this issue

                Created:
                Updated: