Skip navigation
Chris Seepe

Time Zones Across Eloqua

Posted by Chris Seepe Sep 26, 2014

Update 2014-04-14: Contact List Upload Time Zone Details Updated

Update 2017-12-06: API Endpoint Details Updated

 

As most of you know, the Eloqua servers are set to the Eastern (North America) time zone. That means, all dates/times are stored in the database adjusted to GMT-5 (and most likely GMT-4 when Daylight Saving Time is active). I still don't have an exact, technical description of what happens when the time zone switches from GMT-5 to GMT-4, and back; the system just compensates somehow.

 

Anyway, the times in different parts of the application are adjusted to, or displayed in, different time zones. The problem is, there's little-to-no indication of what time zone is being used for each of the date/time displays. I'm trying to compile a list of the different parts of the application, and what time zone is being used. HINT: Most of it is Eastern Time (GMT-5 at least; not sure entirely about DST/GMT-4).

 

The following is my understanding of the current state of the system, and pulled from various Topliners posts (e.g. What should Eloqua focus on for the next release?, Does Time Zone setting work for a separate user or a whole data center?, Adjusting form submisson time to match timezones?). The first link above has a good overview of this information; might also be worth the time to vote. This is not complete nor authoritative. If anything is incorrect or needs clarification, let me know. Tested at least most of these in E10; I believe the majority should apply to E9.

 

Component / Module / ThingTime Zone UsedNotes
Contact List UploadGMT-5

DST Not Observed

(example below)

Contact Filters / Segment Filters / Shared Filters DateTime FieldsEastern (North America) TimePossibly between GMT-5 and GMT-4 depending on Daylight Saving Time*
Campaign Canvas Compare Contact Fields on a DateTime Field / Program Builder Date ComparisonEastern (North America) TimePossibly between GMT-5 and GMT-4 depending on Daylight Saving Time*
Contact Details / Campaign Contact Entry and Next Evaluation Time / Contact Filter Results

Eloqua User Time Zone

Configurable under Setup > Profile
Insight Subscription Report Scheduling / Insight DateTime Fields / Insight DateTime Range PromptsEastern (North America) TimePossibly between GMT-5 and GMT-4 depending on Daylight Saving Time*

Cloud Connectors (Last Run Time, Date Calculator, etc.)

This needs to be retested for the new AppCloud Framework apps.

Greenwich Mean TimeSet to GMT/UTC. DST Ignored.
Form Submission Data (View in Eloqua)Eloqua User Time ZoneConfigurable under Setup > Profile
Form Submission Data (Export) / Form Submission NotificationsEastern (North America) TimePossibly GMT-5 / GMT-4 depending on DST*
Program Builder Test Mode (System Date and Time Override Input)Eastern (North America) TimePossibly GMT-5 / GMT-4 depending on DST*
Program Builder Test Mode (Display Entered Date and Time Override)Eloqua User Time ZoneConfigurable under Setup > Profile
Program Builder Entry / Exit / Evaluation Histories, Last UpdateEloqua User Time ZoneConfigurable under Setup > Profile
CRM Integration External Calls - Actual Data Written to the CRM - Date/Time Stamps (Date Modified, Date Created, etc.), Activity Dates/TimesEastern (North America) TimePossibly GMT-5 / GMT-4 depending on DST*
API Integration (Input and Output) / Asset Last Modified Date through APIEastern (North America) TimePossibly GMT-5 / GMT-4 depending on DST*
Asset Last Modified Date (View in Eloqua)Eloqua User Time ZoneConfigurable under Setup > Profile
CRM Integration Auto Synch Scheduling - Default TimeEastern (North America) TimeAlthough the interface says "10pm EST", that is not accurate; it follows DST.

 

*Switching between DST needs to be verified.

 

 

API Endpoint Details

 

 

bulk/2.0/contacts/exports (Specifically, the resulting contact export sync data)

By default, all times are in Eastern Time and the same as shown in the UI (if your profile is set to Eastern Time). This applies to system-level fields (e.g. {{Contact.CreatedAt}}) as well as customer-created fields (e.g. {{Contact.Field(C_Inquiry_Capture_Date1)}}).

Now, you can add a parameter to your export definition -- "areSystemTimestampsInUTC":"true" -- and this will change only the system-level fields to UTC. Customer-created fields will remain as Eastern Time.

 

NOTE: "Eastern Time" in this context varies between UTC-4 and UTC-5 depending on the date value in that particular fields.

For example, a Date Created (system field) value of "2017-04-30 04:58:49.423" without the areSystemTimestampsInUTC parameter will return "2017-04-30T08:58:49.423Z" with "areSystemTimestampsInUTC":"true" (meaning UTC-4, as DST was active in the Eastern Time Zone on 2017-Apr-30). Similarly, a Date Created value of "2017-12-06 22:01:34.680" without areSystemTimestampsInUTC will return "2017-12-07T03:01:34.680Z" (UTC-5 as DST was not active on 2017-Dec-07) with that parameter set to "true".

 

rest/2.0/data/contact/<id>

Here, all dates (system fields and customer-created fields) are exported in UTC, irrespective of user's profile settings (unlike the Bulk export, where even with areSystemTimestampsInUTC=true, only the system fields are exported in UTC). The timestamps are in epoch time/Unix time (number of seconds from 1970-01-01 00:00:00 UTC). For example, a date of "2017-12-06 22:01:34" as shown in the UI (Profile:Eastern Time) will be exported as 1493542729 (2017-12-07 03:01:34 -- UTC-5), while a date of "2017-04-30 04:58:49" will be 1493542729 (2017-04-30 08:58:49 -- UTC-4).

 

bulk/2.0 fields, definition, and sync createdAt and updatedAt timestamps are UTC.

 

Just to stress this again: If you created a new Contact date field, the Bulk API will always export that value in Eastern Time (UTC-4/UTC-5 depending on that value's date), irrespective of the "areSystemTimestampsInUTC" parameter. However, the REST API will always export that value in UTC with no option to export the as-is database value.

 

 

 

Update: Times in list uploads are processed according to GMT-5 (NO DST).

List Upload Example: Your Eloqua user profile is set to GMT+2. You upload a list with a date/time of "10/13/2014", which is interpreted as "2014-Oct-13 00:00:00". Currently, Eastern (North America) is observing DST, so it's really GMT-4, here. When you view the contact, the time will show as 7:00AM (not 6:00AM).

 

Update: It seems like Eloqua User Profile Time Zones do not observe DST whatsoever; whatever GMT±XX is shown in the selection, that's the time zone offset used (at least for Contact date/time field displays). In the above example, if the Eloqua user profile is set to "(GMT-05:00) Eastern Time (US & Canada)", the time will show as 12:00AM (not 1:00AM).

 

Update: The default scheduling option for auto synchs is "Auto-Synch Runs on Selected Days at 10pm EST?", but that is not accurate. EST (Eastern Standard Time) is UTC-5, but the scheduling option actually switches between EST and EDT. So, if you were in Thailand (ICT, UTC+7, no DST), between Nov 2 and Mar 8 the synch will run at 10:00AM local time, but between Mar 9 and Nov 1, it will run at 9:00AM local time.

 

 

For details on the date/time text format for list uploads, see List Upload Date/Time Formats

Here's a pretty common scenario where Sales people working in Salesforce (or any other CRM) want to be able to add their contacts and leads to an Eloqua campaign on demand.

Currently I have a couple of nurture campaigns that are designed to feed in leads that meet a specific criteria.  However, a lot of times, while sales people are working their leads they determine that it would be nice for some of their leads to also go into a nurture track even if those leads do not meet the criteria.  This scenario is especially common for webinars or roadshow events where you have an initial list of invitees but then sales wants to invite more people.

 

An easy method I came up with was to have the Sales people add their leads and/or contacts into a campaign in SFDC and have my campaign in Eloqua feed in the SFDC campaign members automatically.

 

Here's what's needed:

1.  Eloqua Custom data object with fields for at least the email address, campaign ID, campaign member ID, and campaign member Status - I named it All Campaign Members CDO

2.  An Autosynch that pulls in all new and modified SFDC Campaign Members into eloqua every 30 minutes.

 

What to do:

1.  On the all campaign members CDO, make unique identifier for the CDO records be the campaign member ID because a single SFDC contact/lead record can be part of multiple campaigns.

2.  On the autosynch, set it up to pull all new and modified campaign members from SFDC every 30 minutes - pull in the email address, campaign ID, campaign member ID, campaign member status - have the CDO records map to the Eloqua contacts using the email address.

3.  Once you have the CDO populated, you can now build filters in your eloqua segments to include members of specific campaigns with specific statuses by filtering contacts with linked custom object records that have a specific campaign ID and status.

4.  Using that segment, you can have it feed into any eloqua campaign hourly.

5.  In the Eloqua campaign, you can create shared filter decision rules to route contacts based on their campaign member statuses.

 

This method allows me to give specific instructions to multiple sales reps to add their contacts/leads into a Salesforce campaign and also have them modify those members' statuses so I can route their corresponding contacts in the Eloqua campaign using shared filter member decision rules.

 

Of course there are more applications for this, feel free to share what you think.

 

===

MikeGarcia’s Chocolate Factory … probably not the best practices – but good enough!

MG-009-20140916

Here's a super quick answer for this one:

 

Go to Settings > Company Defaults. You'll see a row for Site ID that's a string of numbers like this: 1234567890

 

Another way to see it is whenever you're in a Form, click the Gear on the upper right and select View Form HTML. You'll see a string near the top that looks like this:

 

action="https://s1234567890.t.eloqua.com/e/f2"

 

The red numbers shown as an example here (they are not red in Eloqua ) comprise the Site ID.

 

Thanks for reading,

Clementina

We are going to be sending email in several languages -- but the obvious question arose -- who should get what translation? (For example, you can't assume that someone in Canada will prefer English.)

I cobbled-together the following code that determines the user's language preference (as set through their browser, and retrieved through the HTTP headers) and puts it into a hidden field.

 

(So far, it seems to work for me.)  The next step would be to create segments based on the language code.

 

<script type='text/javascript' src='http://code.jquery.com/jquery-1.11.0.min.js'></script>

<script type="text/javascript">

 

$.ajax({

    type:     "GET",

    url: "http://ajaxhttpheaders.appspot.com",

    dataType: "jsonp",

    success: function(headers) {

        language = headers['Accept-Language'];

        document.getElementById('userLanguage').value=(language);

    }

});

</script>

 

and then place the following into the form:

 

 

<input type="hidden" name="language" id="userLanguage">

 

 

I'm an Eloqua newbie, so I was wondering if Eloqua already has a way of doing this? (I've looked and asked around, and have come up empty).

 

 

 

Thanks,

 

 

Charlie

Filter Blog

By date: By tag: