With a growing reliance on cloud applications in our day to day operations we can take advantage of some great features such as automatic updates, improved collaboration, and reduced pressure on internal IT teams. With these changes we must also make some compromises to use these apps. Gone are the days of having absolute control over application, features, and security.  These cloud apps will do their best to look familiar to the end user by converting dates, currencies, and languages. While the user sees one value, what is stored in the database may be different.

I wrote a Tech Tuesday a while back about Customer Engagement displaying one time value in the User Interface, but exporting a different value through the web services. This was caused by the web services providing the time in UTC, but the user interface converting it to the local time zone. With the introduction of the server is not running in your time zone (unless you are on GMT), therefore you may run into times when you need to convert the time zone.

In today’s example we’ll look at how to have SmartConnect output Dates and Times in both UTC and your Local Time format. I’m going to import an Account to Customer Engagement and see what date is outputted.

Importing without Conversion

If importing the date without a conversion we see the date was imported, but it is off by 11 hours. This is because my local machine and Customer Engagement are both set to AEDT which is 11 hours ahead of UTC. So I need to tell SmartConnect to add 11 hours to get the local time instead of UTC. This also impacts dates as you can see below that it says the date is yesterday because in UTC it is still the 10th, while in Sydney it is the 11th.

// retrieve current dateTime
nd = new Date();
// format dateTime
q = nd.toISOString().slice(0, 19).replace('T', ' ');

Importing with Conversion

If I modify my script to convert the date I can see that the date and time values now match my local machine.

// Enter your offset
offset = 12; 
// retrieve Current Date
var today = new Date();
// convert to Epoch time
localTime = today.getTime();
// obtain local UTC offset and convert to msec
localOffset = today.getTimezoneOffset() * 60000;
// add epoch time to the offset of your machine
utc = localTime + localOffset; 
// obtain and add destination's UTC time offset
cst = utc + (3600000*offset);
// Convert epoch time to a new date
nd = new Date(cst);
// format dateTime
q = nd.toISOString().slice(0, 19).replace('T', ' ');


In this example we can see how tricky importing dates and times can be to configure correctly. The two factors to note when dealing with dates in Customer Engagement are:

  1. All Data Sources are retrieved in UTC
  2. All Destinations will be imported in the user’s local settings.

If you have any questions, you can reach our support team at