Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get certified in Microsoft Fabric—for free! For a limited time, the Microsoft Fabric Community team will be offering free DP-600 exam vouchers. Prepare now

Reply
Element115
Power Participant
Power Participant

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?

1 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.  

View solution in original post

6 REPLIES 6
v-nikhilan-msft
Community Support
Community Support

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.

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

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.  

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

Helpful resources

Announcements
Las Vegas 2025

Join us at the Microsoft Fabric Community Conference

March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early Bird pricing ends December 9th.

Oct Fabric Update Carousel

Fabric Monthly Update - October 2024

Check out the October 2024 Fabric update to learn about new features.

October NL Carousel

Fabric Community Update - October 2024

Find out what's new and trending in the Fabric Community.