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.
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.
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).
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.
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.