Confluence Cloud Migration Assistant screws up time zones

Dear community,

could it be that the Confluence Cloud Migration Assistant does not properly migrate dates/times (e.g. page creation time)? My test server shows the correct values and also the UTC times are correct in REST calls. After migrating to cloud however the time shows an offset and also the REST calls indicate a wrong UTC value.

On Cloud:

On Server:

The differenece of two two hours matches the current difference from UTC to CEST.

Thank you

Andreas

1 Like

Hi @andreas1. I would recommend reaching out to the support team https://support.atlassian.com/contact/ (Migration Support) and they can help investigate.

Dear @nmansilla . Thanks for the quick reply. I’ll do so. However I was not asking as a user who wants to migrate but as a developer who needs to esnure that this happens in a proper way. Our app data migration depends on this.

The Atlassian support colleagues have been fast: [CONFSERVER-57776] Time is displaying differently after migrating from Server to Cloud - Create and track feature requests for Atlassian products.

1 Like

Hello, @andreas1

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.

1 Like