Forum Discussion
QUESTION::COPY DATA::TIMEZONE ISSUE
I was wondering, does anyone else have the following issue when ingesting datetime timestamps through a pipeline 'Copy data' activity from an on-prem source and all source data is in a timezone other than UTC?
Currently, DST is off. But all incoming timestamps get shifted by the same amount regardless of whether their date occurred when DST was on. In my case, since UTC = EST + 5 when DST is off, even Winter timestamps from previous years are shifter by 5 instead of 4, which is what it should be when DST is off.
Anyone not working in UTC only noticed this?
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.
6 Replies
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.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.
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.
