Why are Marketing Cloud timestamps not stored in the same timezone as Sales Cloud? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Moderator Election Q&A - Questionnaire 2019 Community Moderator Election ResultsWhat is the system timezone in Marketing Cloud and does it consider DST?How does SystemDatetoLocalDate work in ET?Synchronizing data from an external database to Salesforce Marketing CloudAvoiding creating duplicate Contacts in Marketing Cloud when using Sales Cloud recordsMarketing Cloud Triggered SendDo records in a MC Journey get updated in the journey when changed in Sales Cloud?Marketing Cloud Connector not syncing preferencesMarketing Cloud - Timezone - Format/DisplaySales Cloud to Marketing Cloud unsubscribe synchingWhy are Mobile Connect Subscriptions not identified by Contact Key?How to handle Day Light Saving time in AMPScript
How to find out what spells would be useless to a blind NPC spellcaster?
What is the role of the transistor and diode in a soft start circuit?
How to Merge Multiple Columns in to Two Columns based on Column 1 Value?
Check which numbers satisfy the condition [A*B*C = A! + B! + C!]
Denied boarding although I have proper visa and documentation. To whom should I make a complaint?
List *all* the tuples!
How to find all the available tools in mac terminal?
porting install scripts : can rpm replace apt?
What does an IRS interview request entail when called in to verify expenses for a sole proprietor small business?
What is Arya's weapon design?
Why are Kinder Surprise Eggs illegal in the USA?
Why do we bend a book to keep it straight?
How do pianists reach extremely loud dynamics?
How does the particle を relate to the verb 行く in the structure「A を + B に行く」?
Why are there no cargo aircraft with "flying wing" design?
Why did the Falcon Heavy center core fall off the ASDS OCISLY barge?
What does "fit" mean in this sentence?
Identify plant with long narrow paired leaves and reddish stems
Is it ethical to give a final exam after the professor has quit before teaching the remaining chapters of the course?
Why do people hide their license plates in the EU?
List of Python versions
How to react to hostile behavior from a senior developer?
How widely used is the term Treppenwitz? Is it something that most Germans know?
What LEGO pieces have "real-world" functionality?
Why are Marketing Cloud timestamps not stored in the same timezone as Sales Cloud?
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
2019 Moderator Election Q&A - Questionnaire
2019 Community Moderator Election ResultsWhat is the system timezone in Marketing Cloud and does it consider DST?How does SystemDatetoLocalDate work in ET?Synchronizing data from an external database to Salesforce Marketing CloudAvoiding creating duplicate Contacts in Marketing Cloud when using Sales Cloud recordsMarketing Cloud Triggered SendDo records in a MC Journey get updated in the journey when changed in Sales Cloud?Marketing Cloud Connector not syncing preferencesMarketing Cloud - Timezone - Format/DisplaySales Cloud to Marketing Cloud unsubscribe synchingWhy are Mobile Connect Subscriptions not identified by Contact Key?How to handle Day Light Saving time in AMPScript
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
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
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
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
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
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
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
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
marketing-cloud marketing-cloud-connector timezone
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
edited Apr 12 at 14:39
Deployment Failure
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
asked Apr 12 at 14:30
Deployment FailureDeployment Failure
1,38492859
1,38492859
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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).
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was09/29/2016 00:00 AMin SC, it would be stored as09/28/2016 07:00 PMin MC, but from my testing its not its still09/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
Apr 12 at 14:55
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was2019/04/14 8:15:00 AM, this is stored as2019/04/14 7:15:00 AMin SC as they store all timestamps in UTC. In my data extension inside MC this is stored asApr 14 2019 7:15AM, this is also the value queried out as a string.
– Deployment Failure
Apr 12 at 16:08
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
Apr 12 at 16:17
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 stored2:15AMinstead of7:15AM.
– Deployment Failure
Apr 12 at 16:21
|
show 1 more 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
);
);
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
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
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was09/29/2016 00:00 AMin SC, it would be stored as09/28/2016 07:00 PMin MC, but from my testing its not its still09/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
Apr 12 at 14:55
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was2019/04/14 8:15:00 AM, this is stored as2019/04/14 7:15:00 AMin SC as they store all timestamps in UTC. In my data extension inside MC this is stored asApr 14 2019 7:15AM, this is also the value queried out as a string.
– Deployment Failure
Apr 12 at 16:08
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
Apr 12 at 16:17
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 stored2:15AMinstead of7:15AM.
– Deployment Failure
Apr 12 at 16:21
|
show 1 more 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).
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was09/29/2016 00:00 AMin SC, it would be stored as09/28/2016 07:00 PMin MC, but from my testing its not its still09/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
Apr 12 at 14:55
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was2019/04/14 8:15:00 AM, this is stored as2019/04/14 7:15:00 AMin SC as they store all timestamps in UTC. In my data extension inside MC this is stored asApr 14 2019 7:15AM, this is also the value queried out as a string.
– Deployment Failure
Apr 12 at 16:08
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
Apr 12 at 16:17
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 stored2:15AMinstead of7:15AM.
– Deployment Failure
Apr 12 at 16:21
|
show 1 more 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).
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
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).
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
answered Apr 12 at 14:49
Jackson ChenJackson Chen
651119
651119
This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was09/29/2016 00:00 AMin SC, it would be stored as09/28/2016 07:00 PMin MC, but from my testing its not its still09/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
Apr 12 at 14:55
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was2019/04/14 8:15:00 AM, this is stored as2019/04/14 7:15:00 AMin SC as they store all timestamps in UTC. In my data extension inside MC this is stored asApr 14 2019 7:15AM, this is also the value queried out as a string.
– Deployment Failure
Apr 12 at 16:08
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
Apr 12 at 16:17
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 stored2:15AMinstead of7:15AM.
– Deployment Failure
Apr 12 at 16:21
|
show 1 more comment
This is weird because their documentation says otherwise: help.salesforce.com/…. In the documentation it gives an example where if the date was09/29/2016 00:00 AMin SC, it would be stored as09/28/2016 07:00 PMin MC, but from my testing its not its still09/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
Apr 12 at 14:55
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
The account is set to GMT * (The * indicates its observing DST so its really BST). So for example a date I stored was2019/04/14 8:15:00 AM, this is stored as2019/04/14 7:15:00 AMin SC as they store all timestamps in UTC. In my data extension inside MC this is stored asApr 14 2019 7:15AM, this is also the value queried out as a string.
– Deployment Failure
Apr 12 at 16:08
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
Apr 12 at 16:17
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 stored2:15AMinstead of7:15AM.
– Deployment Failure
Apr 12 at 16:21
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
Apr 12 at 14:55
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
Apr 12 at 14:55
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
That's interesting. So what timezone are you seeing in MC?
– Jackson Chen
Apr 12 at 16:04
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
Apr 12 at 16:08
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
Apr 12 at 16:08
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
Apr 12 at 16:17
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
Apr 12 at 16:17
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
Apr 12 at 16:21
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
Apr 12 at 16:21
|
show 1 more comment
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
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
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
