The Community is hosting an End of Summer sweepstakes! Participants must complete tasks to earn tickets that will enter them with a chance to win a free year of Constant Contact and other great prizes!*
*No Purchase Necessary. For Official Rules, visit here. Constant Contact’s End of Summer 2020 Sweepstakes ends on October, 20, 2020 at 11:50 PM EST.

Event Marketing API time zone offset bug

Highlighted
Participant

Event Marketing API time zone offset bug

There is a bug in the way that StartDate, EndDate and other dates are returned by the Event Marketing API.  Specifically, my company is in the Pacific time zone.  So, I selected that time zone when creating some events.  Unfortunately, I found that the XML date-times returned by the API are off by 2 hours.


For example, I set a date and time of 12/6/2010 1:00 PM (Pacific time zone) for the StartDate of an event.  The value in the XML is "2010-12-06T18:00:00-05:00", which is actually 6:00 PM Eastern, 3:00 PM Pacific.


Strangely, Constant Contact must be storing the time correctly somewhere (separate time zone field?), because they do display the right time and time zone in their web site, just not in the XML returned by their API.


Do I need to start blindly subtracting 2 hours from all times returned by the API, or can this be fixed ASAP?  I also don't want to implement a big hack that could cause issues with daylight saving time.

Paul

4 REPLIES 4
Highlighted
Employee

Re: Event Marketing API time zone offset bug

I am seeing an issue with the returned event time, but my assessment of this is a little different.


 


Setting an event to 1:00pm PST is returning 18:00-5:00, which is 13:00 (1:00pm). It looks like we're ignoring the time zone altogether, and returning the 1:00pm EST. If we modify the time zone to be something like Fiji (GMT + 12), the API still returns 18:00-5:00 (1:00pm EST). So I believe that the actual time being returned is correct, it is simply ignoring the time zone and assuming it is set to EST regardless of what is entered into the user interface at www.constantcontact.com.


 


I believe this was intended to return an UTC time stamp like "2010-12-21T18:00:00.000Z" which would be correct.


 


I am going to be submitting this to our engineers to look at, and will respond to this post once I have more information regarding this. I do apologize for any inconvenience this has caused, please let us know if you have any further questions. Thanks.

David J

Highlighted
Participant

2 hour offset is real

As I mentioned, the time is coming back offset by 2 hours.  I am telling you what happens when the string is directly parsed as an ISO 8601 date-time by .NET, based on how that time format is documented.  The 18:00/6 PM portion in the string is the local time, and the offset indicates how that local time is different from UTC.  So, -5 basically indicates a time in the Eastern time zone (6 PM), which is then calculated by .NET on my computer to be an earlier nominal time in our Pacific time zone (3 PM).

Paul

Highlighted
Employee

Re: 2 hour offset is real

Thank you for clarifying this. I am certainly not an expert in date/time stamps, however after reading the ISO I have a much better understanding of how this works. I will let you know as soon as I have any further information on this. Thanks.

David J

Highlighted
Participant

Status of fix for 2 hour offset in event starting, ending times?

Is this issue being fixed?  Until then, I have a hack in my code to blindly subtract the extra 2 hours from the starting and ending date-time of every event.  I am leaving the other fields alone, since they are presumably OK and in Eastern time.

Paul

Developer Portal

View API documentation, code samples, get your API key.

Visit Page

Constant Contact 2020 End of Summer Community Sweepstakes!

The Constant Contact User Community is hosting a sweepstakes. The more you participate, the more chances you have to win! Read on to learn more...

Read More
Featured