Forum Discussion
QUESTION::COPY DATA::TIMEZONE ISSUE
- 2 years ago
How can you say 'solved the issue'? ABSOLUTELY NOT! Because as long as the Copy data/data gateway changes the incoming timestamps to the wrong UTC offset to boot, it is not solved! 😠😠ğŸ˜
FYI Microsoft acknowledged this is a bug that will be fixed in a future update of the data gateway. That's what I have been told. So do not tell me that it is a solved issue when it is not. Further, we have been told the fix should be done by EOM.
Hi Element115
Thanks for using Fabric Community.
Similar cases have been observed in the past week:
Fabric pipeline copy activity converts time to UTC - Microsoft Fabric Community
Re: Copy activity UTC/local time zone conversion p... - Microsoft Fabric Community
Already support tickets have been opened and are in progress. I will keep you posted regarding the updates.
Appreciate your patience.
- Anonymous2 years agoNot applicable
Hi Element115
Can you please try the below steps:
1) Update to the latest on-prem version.
Currently supported monthly updates to the on-premises data gateways | Microsoft Learn
2)Try changing the mapping in the copy activity of the timestamp column from timestamp to string.if the issue still persists even after following the above steps, please do let me know. Hope this helps.
- Element1152 years agoMemorable Member
1__ already tried as soon as it came out: the bug is still there
2__also tried this workaround: convert the timestamp at source to string or with Mapping to string in Copy data settings, and then reconvert to datetime inside the report, which does preserve the original timestamp as is, BUT that's not a solution, it's a workaround that eats unnecessary CU when multiple refreshes per day are triggered.
- Anonymous2 years agoNot applicable
Hi Element115
Thanks for the details. The above troubleshooting steps have solved the issue for the other customers. As you said the second one is a work around, but did solve the issue.
Thanks