Summary

Timezone differences are not taken into account when importing a JIRA Server backup into Cloud.
JIRA backup doesn't seem to store the timezone in entities.xml (check 'Notes' below), so import may shift dates if they are interpreted incorrectly. This happens if the backup exported registered the dates using the timezone used in Jira Server (which seems to happen), while Jira Cloud interpreted as UTC. That makes the times and dates in the UI to be shifted as many hours as the time difference between the instances.

Affected dates are:

1. History dates (in 'all' tab in issue view)
2. Created date
3. Etc.

Apparently, dates like 'sprint start dates' are not affected, as they use a different data type. This is actually even worse because sprints and issues dates may become inconsistent (some are shifted and some are not), breaking reports.

2023-03-31 09:42:26,001 http-nio-8080-exec-17 ERROR lenard 582x556x1 1t209dy 0:0:0:0:0:0:0:1 /rest/migration/latest/check/1c3033fe6216a0eb20d64fc87deda54661977b8b [c.a.p.r.c.error.jersey.ThrowableExceptionMapper] Uncaught exception thrown by REST service: Caught PSQLException for select "AO_D9132D_PLAN"."ID" from "public"."AO_D9132D_PLAN" "AO_D9132D_PLAN" limit ?
com.querydsl.core.QueryException: Caught PSQLException for select "AO_D9132D_PLAN"."ID" from "public"."AO_D9132D_PLAN" "AO_D9132D_PLAN" limit ?
	at com.querydsl.sql.DefaultSQLExceptionTranslator.translate(DefaultSQLExceptionTranslator.java:50)
	at com.querydsl.sql.Configuration.translate(Configuration.java:459)

Steps to Reproduce

1. Create a JIRA Server in a specific timezone different than UTC (database timezone)
2. Create tickets and create history (by editing it, adding to sprints, etc.)
3. Migrate from this Server to Cloud
4. Change your profile timezone in both to match so you can compare

Expected Results

The history dates, created dates, etc. are the same.

Actual Results

The dates are not the same.

Notes

In an actual test import, we could see, this was the date as retrieved using a 'select' in Jira Server (source) database:

2018-03-09 13:50:30.51-03

This was the data in Cloud (destination):

2018-03-09T13:50:30.51Z

This was what was registered in entities.xml:

<Issue id="10001" key="PROJ-2" [...] created="2018-03-09 13:50:30.51"  [...] />

No timezone was stored, so Jira Core interprets it as GMT (the Z at the end actually means GMT), though it should interpret as GMT-3 in this case.

After that, we opened the ticket in both source and destination, making sure the user timezone matched, and we could see this:

There's a 3 hours difference. Though the ticket was created only 1 hour ealier, in the destination it says 4 hours ago (I hadn't even installed Jira 4 hours earlier). If we place the pointer over the date says 09/Mar/18 1:50 PM in source Jira while destination says 09/Mar/18 10:50 AM, though user timezone is the same in both instances (GMT-3).

Notice that this test was done with a recently installed Jira Server (with no advanced configuration) and only 1 project and 2 tickets (a very simple configuration). The destination Jira Cloud was a clean one.

Workaround

Use either of the workarounds below, not both.

1) Edit the backup file (preferred)

1. Check the entities.xml file that was generated.
2. Look for lines that look like this:

   <OSPropertyEntry id="10500" entityName="jira.properties" entityId="1" propertyKey="jvm.system.timezone" type="5"/>
   <OSPropertyString id="10500" value="America/New_York"/>
   

• • The IDs may be the different, but the 'propertyKey' is always going to be jvm.system.timezone, so you can search for it

1. If the file contains these lines, you shouldn't be impacted, as a fix was applied to take advantage of it
2. If it doesn't, add them next to other OSPropertyEntry and OSPropertyString respectively
3. Make sure the ID is not used by other OSPropertyEntry element. If it is, replace both ID (which must be identical) by another unused one.
4. In the 'OSPropertyString' entry, make sure you change the value to the timezone from your source Jira.

2) Change DB Timezone

This only works with PostgreSQL. If you use MySQL you will first need to export the backup and import it into a staging JIRA Server using PostgreSQL.
You may want to take a DB backup before trying this workaround. 

1. Stop Jira Server
2. Change Jira Server timezone, by Setting the timezone for the JAVA environment to UTC
   • Alternatively, if the timezone parameter is not being used, you can change the timezone for the server (machine) running Jira Server to UTC
3. Start Jira (the User Timezone in System Information page must show the timezone change)
   • Notice that this may change most users timezone as well, as Default User Timezone by defaults is set to the system timezone and all users that haven't set their own timezone will use it.
4. Generate a new backup and re-do the migration

For further details you can also refer to the below KB (for Jira Server):

• Incorrect Times Displayed in JIRA