I currently have an email script I am using to populate a time, and it is populating 1 hour earlier than the value that is in SFDC. We are using the email script to pull in the time of the earliest (date-wise) item within the object. Our Salesforce Dev team has informed me that the times show in local time zones in SFDC, so I don't believe that should be an issue but am not sure. Any help is appreciated.
#set( $FlightLegsFromEarliest = $sorter.sort($Flight_Leg__cList,["Est_Departure_Time_EST__c:asc"]) )
#foreach($Flight_Leg__c in $FlightLegsFromEarliest )
#if(${Flight_Leg__c.Status__c}== "Booked")
#set( $matchedFlightLeg = $Flight_Leg__c )
#break
#end
#end
##OutPut Est_Departure_Time_EST__c
#if($matchedFlightLeg)
$matchedFlightLeg.Est_Departure_Time_EST__c##
#end
Shot in the dark here. Is one of your systems not accounting for daylight vs standard time?
It's possible that the time is "correct" for standard but an hour off for daylight.
I was thinking about that - our Salesforce timestamp is EST and Marketo is EDT. Do you think that's the issue? If so, do you know the best way to resolve?
Highly doubt this has anything to do with Daylight Savings. Rather, it directly relates to different time zones.
Is the SFDC field a standard Datetime? If so, the value is stored in UTC — regardless of display — just as it is in Marketo. But the name having “EST” in it is curious. Is it actually a String in SFDC that hard-codes a local time? That’s very dangerous but changes the required solution.
It looks like we have another field 'Estimated Departure Time' which shows the value stored in UTC (attaching a screenshot). Would it be easier for us to use this value instead?
Not necessarrily. Building further onto @SanfordWhiteman 's comments, the value is most likely stored in the database in a standardized time zone. If you want it displayed in a different time zone, you can update your script to specify the output time zone.
is there documentation on how to display in a different timezone? or can anyone can point me in the right direction? thank you!
Yes, I would certainly recommend using the actual, unadjusted time — the one stored in UTC. All attempts to store datetimes with some sort of hard-coded offset eventually fail (timezones are not static beasts, UTC never changes).
The seminal post on all Velocity day, time, and timezone matters is:
Velocitips: Switch email content based on day/time