Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-26039

Verify the system timezone when an XML backup is restored

XMLWordPrintable

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      When migrating JIRA to another server, if there are timezone inconsistencies between the two servers it can cause considerable problems with the new server that may not be discovered until problems have been introduced into the dataset. Please enhance JIRA to timestamp an XML backup and provide a warning during XML restore that the backup does not match the server time of the instance it is being imported into.

      • Times stored in the database is based on the JIRA JVM user timezone

      Workaround

      In order to restore the times back to their last known working form, the below process can be used for the new server:

      1. Generate an XML backup from the previous server, or obtain the last-known working one and copy it to the new JIRA server.
      2. Schedule a downtime window.
      3. Stop the new JIRA server.
      4. 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).
      5. Start the new JIRA server.
      6. Import the XML backup from the previous server.
      7. Test 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.

      1. Schedule a downtime window.
      2. Export the XML backup.
      3. Stop JIRA.
      4. 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).
      5. Start JIRA.
      6. Import the XML backup.
      7. Test JIRA.

            [JRASERVER-26039] Verify the system timezone when an XML backup is restored

            Kerrod Williams (Inactive) added a comment -

            Thanks for taking the time to raise this issue.

            Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

            I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

            Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.
            Kind Regards,
            Kerrod Williams
            JIRA Product Management
            kerrod.williams at atlassian dot com

            Kerrod Williams (Inactive) added a comment - Thanks for taking the time to raise this issue. Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts . In part, that means concentrating on those issues that resonate the most with our users. I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue. Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me. Kind Regards, Kerrod Williams JIRA Product Management kerrod.williams at atlassian dot com

            Tyler Bradford added a comment -

            The workaround that Matt is suggesting certainly seems reasonable, but there's something else that I'd like to suggest; why not put a simple NTP client within tomcat that talks to 0.atlassian.pool.ntp.org & 1.atlassian.pool.ntp.org, with an advanced configuration option to either a) specify your own NTP servers or b) base timestamps off the system clock, with a warning that YMMV? I mean, it's web-based, one can safely assume it would be able to make NTP requests, and the UPM is already connecting to marketplace.atlassian.com by default, not to mention the default for analytics.

            I realize that Atlassian might not want to be in the position of responsibility for assuring their NTP servers are 24/7 & 100% accurate, but I personally would choose that option rather than have everything be based on local system clocks. Heck, even make the defaults to pool.ntp.org, and add a region localization button as part of the initial config screens to select the NTP pool region. It would make all of this a lot simpler by having everything be +0000 UTC in the database, and then all localization can either be set system-wide or at the user level.

            Tyler Bradford added a comment - The workaround that Matt is suggesting certainly seems reasonable, but there's something else that I'd like to suggest; why not put a simple NTP client within tomcat that talks to 0.atlassian.pool.ntp.org & 1.atlassian.pool.ntp.org, with an advanced configuration option to either a) specify your own NTP servers or b) base timestamps off the system clock, with a warning that YMMV? I mean, it's web-based, one can safely assume it would be able to make NTP requests, and the UPM is already connecting to marketplace.atlassian.com by default, not to mention the default for analytics. I realize that Atlassian might not want to be in the position of responsibility for assuring their NTP servers are 24/7 & 100% accurate, but I personally would choose that option rather than have everything be based on local system clocks. Heck, even make the defaults to pool.ntp.org, and add a region localization button as part of the initial config screens to select the NTP pool region. It would make all of this a lot simpler by having everything be +0000 UTC in the database, and then all localization can either be set system-wide or at the user level.

            MattS added a comment -

            From the linked GH issue it sounds like the workaround is to force the Java timezone using a command line JVM flag. Which means that JIRA data can never be moved to a new timezone, you always have to preserve the timezone it started with.

            MattS added a comment - From the linked GH issue it sounds like the workaround is to force the Java timezone using a command line JVM flag. Which means that JIRA data can never be moved to a new timezone, you always have to preserve the timezone it started with.

            MattS added a comment - - edited

            I can't believe I got bitten by this again! A production JIRA server crashed so I started up the standby server, which has the data mirrored from the master database and attachments etc rsynced.
            Everything was fine until someone noticed that the system timezone on the standby was not the same as the production instance. All existing issues suddenly had their dates off by 8 hours.

            I wonder if there could be a check in JIRA admin-land that the timezone last used for the data matches the current timezone.

            MattS added a comment - - edited I can't believe I got bitten by this again! A production JIRA server crashed so I started up the standby server, which has the data mirrored from the master database and attachments etc rsynced. Everything was fine until someone noticed that the system timezone on the standby was not the same as the production instance. All existing issues suddenly had their dates off by 8 hours. I wonder if there could be a check in JIRA admin-land that the timezone last used for the data matches the current timezone.

            MattS added a comment -

            1. The dates are created in JIRA, so pre 4.4 should be using the local JVM timezone. I don't believe the database's timezone is used. So I think that importing an XML backup full of dates in PST would be the same as upgrading a database full of dates in PST. Answer: both, but this really needs testing to be sure.

            2. The usual advice of "change one thing at a time" applies, for sure. I think I'd advise upgrading on the same machine, same timezone. Then move the data to the new JIRA server with a different timezone and adjust the timezone in JIRA to fit.

            The problem is that though that will preserve the correct dates, newly created issues will be incorrect, so it's not a workaround. The root cause is that JIRA doesn't store dates with a timezone (or am I mistaken about that).

            MattS added a comment - 1. The dates are created in JIRA, so pre 4.4 should be using the local JVM timezone. I don't believe the database's timezone is used. So I think that importing an XML backup full of dates in PST would be the same as upgrading a database full of dates in PST. Answer: both, but this really needs testing to be sure. 2. The usual advice of "change one thing at a time" applies, for sure. I think I'd advise upgrading on the same machine, same timezone. Then move the data to the new JIRA server with a different timezone and adjust the timezone in JIRA to fit. The problem is that though that will preserve the correct dates, newly created issues will be incorrect, so it's not a workaround. The root cause is that JIRA doesn't store dates with a timezone (or am I mistaken about that).

            Giles Gaskell [Atlassian] added a comment - - edited

            Hi Matt,

            Thanks for logging this issue.

            Before I amend the documentation, could I ask you a few questions to clarify some of the details:

            1. Would this issue only affect JIRA upgrades which involve an XML export from the original JIRA installation, followed by an XML import to the upgraded JIRA installation?
              • Or, would an in-place database upgrade of JIRA (i.e. documented in the Upgrading JIRA Manually procedure) be affected by this issue too?
            2. Is there a way to avoid this issue when upgrading JIRA (since it might be worth documenting a workaround if this isn't already a known issue in JIRA itself)? Should the person upgrading JIRA first change:
              • The timezone on their target machine to PST before installing JIRA 4.4 on it (and then if necessary, change the System Default setting of the Default user time zone to PST too)? (They would then import their JIRA data on that target machine running JIRA 4.4.)
              • The local timezone in JIRA on the original machine to UTC before exporting the JIRA data from it?

            Cheers,
            Giles.

            Giles Gaskell [Atlassian] added a comment - - edited Hi Matt, Thanks for logging this issue. Before I amend the documentation, could I ask you a few questions to clarify some of the details: Would this issue only affect JIRA upgrades which involve an XML export from the original JIRA installation, followed by an XML import to the upgraded JIRA installation? Or, would an in-place database upgrade of JIRA (i.e. documented in the Upgrading JIRA Manually procedure) be affected by this issue too? Is there a way to avoid this issue when upgrading JIRA (since it might be worth documenting a workaround if this isn't already a known issue in JIRA itself)? Should the person upgrading JIRA first change: The timezone on their target machine to PST before installing JIRA 4.4 on it (and then if necessary, change the System Default setting of the Default user time zone to PST too)? (They would then import their JIRA data on that target machine running JIRA 4.4.) The local timezone in JIRA on the original machine to UTC before exporting the JIRA data from it? Cheers, Giles.

              Unassigned Unassigned
              73d805a2526b MattS
              Votes:
              3 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: