I have seen several old conversations about this topic with no resolutions so I am going to start a new one.
I am creating a custom event with the following request
{
"input": [{
"activityDate": (new Date ().toISOString ())
, "activityTypeId": 100045
, "attributes": [
{"name": "Event Date" , "value": "2022-06-26T21:00:00.000Z"}
, {"name": "Mobile Phone" , "value": "###-###-####"}
, {"name": "Send Live Notifications" , "value": false}
, { "name": "Send Recording Notifications" , "value": true}
]
, "leadId": #######
, "primaryAttributeValue": "..."
}]
}
As you can see I am passing the Event Date in as UTC which should translate to 5pm EDT (which our instance of Marketo is setup as). But what is being displayed in the activity dialog is 2022-06-26 16:00:00. This is either CDT or EST.
At first I thought this might just be a display issue. But when I pulled the data through the API this is what I found.
{
"id": 1066793303,
"marketoGUID": "1066793303",
"leadId": ######,
"activityDate": "2022-06-26T00:36:24Z",
"activityTypeId": 100045,
"primaryAttributeValueId": 17,
"primaryAttributeValue": "...",
"attributes": [
{
"name": "Event Date",
"value": "2022-06-26 16:00:00"
},
{
"name": "Mobile Phone",
"value": "###-###-###"
},
{
"name": "Send Live Notifications",
"value": false
},
{
"name": "Send Recording Notifications",
"value": true
}
]
}
The attribute isn't stored as a proper UTC date (see Activity Date field above). So if our systems our using that date for anything it becomes very sketchy data because most processors will assume the date is local time if there is no timezone data attached.
Does anyone know the true workings of the field? Is the REST server in US Central Time and all attribute dates will always be US Central Time? Do the attribute dates never account for Daylight Savings Time and therefore my processors will have to keep that in mind?
If I cannot get a satisfactory answer in the next few days, I will have to reconfigure my Custom Attribute to change the Event Date to an integer field and store the date in Unix Epoch Time. It will be a pain but at least I know that the API will not convert the integer to another one and will be able to get the appropriate time.
.png)