We are in New Zealand, and as a Solution Partner have done several Confluence migrations from Server to Cloud. So far all of these were from Postgres databases, from environments configured to have GMT+12 as the JVM timezone via “-Duser.timezone”.
Every single time – we had to reach out to Support to run some mysterious query post-migration to change the timestamps.
Apparently Confluence Server doesn’t store the timezone in the database when storing timestamps, so on import to Cloud all of them look like they are in UTC. This is not CCMA-specific, a simple export/import of a space has the same problem.
The “workaround” mentioned in the linked CONFSERVER-57776 is useless at the time of migration.
Changing JVM to UTC at the time of migration is too late.
I don’t know if Confluence Cloud does maintain timezone in the timestamps.
I believe Atlassian Migration Support runs the query that reads timestamps as if they were in UTC and then puts them back in the timezone of the instance, effectively adding an explicit offset.
My concern was always about the completeness of this update – the do update CONTENT table, but what about other places? And yes, in the case of CCMA – what about data maintained and being migrated by apps?
I also have a suspicion that whenever daylight savings kicked in, as in “in the past” – the resulting effective timestamps on import to Cloud would drift by an hour.