Ttyjfyk

Relations between two reciprocal partial derivatives?

How to delete random line from file using Unix command?

How to copy the contents of all files with a certain name into a new file?

I could not break this equation. Please help me

system() function string length limit

Can smartphones with the same camera sensor have different image quality?

Is above average number of years spent on PhD considered a red flag in future academia or industry positions?

What can I do if neighbor is blocking my solar panels intentionally?

What information about me do stores get via my credit card?

Didn't get enough time to take a Coding Test - what to do now?

The variadic template constructor of my class cannot modify my class members, why is that so?

Can a 1st-level character have an ability score above 18?

How are presidential pardons supposed to be used?

Match Roman Numerals

How should I replace vector<uint8_t>::const_iterator in an API?

When did F become S in typeography, and why?

How to pronounce 1ターン?

How to remove this toilet supply line that seems to have no nut?

Did God make two great lights or did He make the great light two?

Are my PIs rude or am I just being too sensitive?

Was credit for the black hole image misattributed?

Windows 10: How to Lock (not sleep) laptop on lid close?

Wall plug outlet change

Am I ethically obligated to go into work on an off day if the reason is sudden?

Why are Marketing Cloud timestamps not stored in the same timezone as Sales Cloud?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;

4

1

I have both Sales Cloud and Marketing Cloud connected and use data shared for a Journey when new records are created.

In my object that is triggered in the journey I have a Date/Time field which gets stored in SC in UTC, however in MC timezone settings are not stored in the field.

This means when using functions like SystemDateToLocalDate(@recordTimestamp) returns the wrong time as it thinks the original date is in CST (the system timezone instead of UTC).

Is this expected behavior?

marketing-cloud marketing-cloud-connector timezone

share|improve this question

edited yesterday

Deployment Failure

asked yesterday

Deployment FailureDeployment Failure

1,38092858

add a comment | 

4

1

I have both Sales Cloud and Marketing Cloud connected and use data shared for a Journey when new records are created.

In my object that is triggered in the journey I have a Date/Time field which gets stored in SC in UTC, however in MC timezone settings are not stored in the field.

This means when using functions like SystemDateToLocalDate(@recordTimestamp) returns the wrong time as it thinks the original date is in CST (the system timezone instead of UTC).

Is this expected behavior?

marketing-cloud marketing-cloud-connector timezone

share|improve this question

edited yesterday

Deployment Failure

asked yesterday

Deployment FailureDeployment Failure

1,38092858

add a comment | 

I have both Sales Cloud and Marketing Cloud connected and use data shared for a Journey when new records are created.

In my object that is triggered in the journey I have a Date/Time field which gets stored in SC in UTC, however in MC timezone settings are not stored in the field.

This means when using functions like SystemDateToLocalDate(@recordTimestamp) returns the wrong time as it thinks the original date is in CST (the system timezone instead of UTC).

Is this expected behavior?

marketing-cloud marketing-cloud-connector timezone

share|improve this question

edited yesterday

Deployment Failure

asked yesterday

Deployment FailureDeployment Failure

1,38092858

share|improve this question

edited yesterday

Deployment Failure

asked yesterday

Deployment FailureDeployment Failure

1,38092858

share|improve this question

edited yesterday

Deployment Failure

asked yesterday

Deployment FailureDeployment Failure

1,38092858

asked yesterday

Deployment FailureDeployment Failure

1,38092858

asked yesterday

Deployment FailureDeployment Failure

1,38092858

1 Answer
1

active

oldest

votes

4

Yes this is expected. Server times for ExactTarget/Marketing Cloud is in CST: Central Standard Time (UTC minus six hours) and also the server time does not change with standard versus daylight savings time.

There are some weird behaviors with different stacks. Apparently Stack 4 is in US Mountain time (UTC minus 7 hours).

share|improve this answer

answered yesterday

Jackson ChenJackson Chen

594118

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was 09/29/2016 00:00 AM in SC, it would be stored as 09/28/2016 07:00 PM in MC, but from my testing its not its still 09/29/2016 00:00 AM. In my test I simply queried out the data extension and stored to a text field which should bypass any UI time offsets.
  
  – Deployment Failure
  yesterday
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That's interesting. So what timezone are you seeing in MC?
  
  – Jackson Chen
  yesterday
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was 2019/04/14 8:15:00 AM, this is stored as 2019/04/14 7:15:00 AM in SC as they store all timestamps in UTC. In my data extension inside MC this is stored as Apr 14 2019 7:15AM, this is also the value queried out as a string.
  
  – Deployment Failure
  yesterday
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  See this quote in the same link you provided "Ensure that you use the proper offset when manipulating date and time information synchronized from the Sales Cloud to the Marketing Cloud." My interpretation is that they are telling us the date is stored in CST in MC in the event you are manipulating the data after it gets to MC. It's telling you that it is NOT stored in GMT as it is on SFDC. In other words, while the numbers are different, those both represent the exact same time.
  
  – Jackson Chen
  yesterday
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  How I've interpreted that last line is that we must use offsets get back to the original timezone and this would be totally fine if the times stored between SC and MC were different. But they're not, they are the same values, just in MC its assumed that timezone is CST. The documentation states it will actually store whatever the converted CST time is. In my example above it should have stored 2:15AM instead of 7:15AM.
  
  – Deployment Failure
  yesterday
  

  
  
  
  

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f257650%2fwhy-are-marketing-cloud-timestamps-not-stored-in-the-same-timezone-as-sales-clou%23new-answer', 'question_page');

);

Post as a guest

Name

Email

Required, but never shown

4

Yes this is expected. Server times for ExactTarget/Marketing Cloud is in CST: Central Standard Time (UTC minus six hours) and also the server time does not change with standard versus daylight savings time.

There are some weird behaviors with different stacks. Apparently Stack 4 is in US Mountain time (UTC minus 7 hours).

share|improve this answer

answered yesterday

Jackson ChenJackson Chen

594118

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was 09/29/2016 00:00 AM in SC, it would be stored as 09/28/2016 07:00 PM in MC, but from my testing its not its still 09/29/2016 00:00 AM. In my test I simply queried out the data extension and stored to a text field which should bypass any UI time offsets.
  
  – Deployment Failure
  yesterday
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That's interesting. So what timezone are you seeing in MC?
  
  – Jackson Chen
  yesterday
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was 2019/04/14 8:15:00 AM, this is stored as 2019/04/14 7:15:00 AM in SC as they store all timestamps in UTC. In my data extension inside MC this is stored as Apr 14 2019 7:15AM, this is also the value queried out as a string.
  
  – Deployment Failure
  yesterday
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  See this quote in the same link you provided "Ensure that you use the proper offset when manipulating date and time information synchronized from the Sales Cloud to the Marketing Cloud." My interpretation is that they are telling us the date is stored in CST in MC in the event you are manipulating the data after it gets to MC. It's telling you that it is NOT stored in GMT as it is on SFDC. In other words, while the numbers are different, those both represent the exact same time.
  
  – Jackson Chen
  yesterday
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  How I've interpreted that last line is that we must use offsets get back to the original timezone and this would be totally fine if the times stored between SC and MC were different. But they're not, they are the same values, just in MC its assumed that timezone is CST. The documentation states it will actually store whatever the converted CST time is. In my example above it should have stored 2:15AM instead of 7:15AM.
  
  – Deployment Failure
  yesterday
  

  
  
  
  

add a comment | 

4

Yes this is expected. Server times for ExactTarget/Marketing Cloud is in CST: Central Standard Time (UTC minus six hours) and also the server time does not change with standard versus daylight savings time.

There are some weird behaviors with different stacks. Apparently Stack 4 is in US Mountain time (UTC minus 7 hours).

share|improve this answer

answered yesterday

Jackson ChenJackson Chen

594118

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was 09/29/2016 00:00 AM in SC, it would be stored as 09/28/2016 07:00 PM in MC, but from my testing its not its still 09/29/2016 00:00 AM. In my test I simply queried out the data extension and stored to a text field which should bypass any UI time offsets.
  
  – Deployment Failure
  yesterday
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That's interesting. So what timezone are you seeing in MC?
  
  – Jackson Chen
  yesterday
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was 2019/04/14 8:15:00 AM, this is stored as 2019/04/14 7:15:00 AM in SC as they store all timestamps in UTC. In my data extension inside MC this is stored as Apr 14 2019 7:15AM, this is also the value queried out as a string.
  
  – Deployment Failure
  yesterday
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  See this quote in the same link you provided "Ensure that you use the proper offset when manipulating date and time information synchronized from the Sales Cloud to the Marketing Cloud." My interpretation is that they are telling us the date is stored in CST in MC in the event you are manipulating the data after it gets to MC. It's telling you that it is NOT stored in GMT as it is on SFDC. In other words, while the numbers are different, those both represent the exact same time.
  
  – Jackson Chen
  yesterday
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  How I've interpreted that last line is that we must use offsets get back to the original timezone and this would be totally fine if the times stored between SC and MC were different. But they're not, they are the same values, just in MC its assumed that timezone is CST. The documentation states it will actually store whatever the converted CST time is. In my example above it should have stored 2:15AM instead of 7:15AM.
  
  – Deployment Failure
  yesterday
  

  
  
  
  

add a comment | 

Yes this is expected. Server times for ExactTarget/Marketing Cloud is in CST: Central Standard Time (UTC minus six hours) and also the server time does not change with standard versus daylight savings time.

There are some weird behaviors with different stacks. Apparently Stack 4 is in US Mountain time (UTC minus 7 hours).

share|improve this answer

answered yesterday

Jackson ChenJackson Chen

594118

share|improve this answer

answered yesterday

Jackson ChenJackson Chen

594118

answered yesterday

Jackson ChenJackson Chen

594118

answered yesterday

Jackson ChenJackson Chen

594118