QUESTION::COPY DATA::TIMEZONE ISSUE

[Element115]

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?

[v-nikhilan-msft]

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.

[v-nikhilan-msft]

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.

[Element115]

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.

[v-nikhilan-msft]

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

[Element115 · Accepted solution]

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.  

[v-nikhilan-msft]

I meant to say it resolved the issue temporarily @Element115 .Glad that you got the details from our support team. Kindly update here if you have the details so that it will be helpful for other community members.
Thanks