For context, we previously fixed parsing of startDate and endDate
fields on campaigns to parse through the parent account's timezone into
UTC as YYYYMMDD date strings. This remains in accordance with our best
understanding of the nature of those two fields based on the Campaign API
Docs.
This worked for most customers but for some it resulted in an error
because the request for their account resulted in an empty resultset.
Based on my understanding of the API Docs there should be no reason
why a ManagedCustomer shouldn't come back from the
ManagedCustomerService for a customer id that the client has access
to. Nevertheless we've seen multiple occasions where none come back.
Falling back to UTC seems like a reasonable default although it's almost
certainly wrong.
Motivation
https://stitchdata.atlassian.net/browse/SUP-292
For context, we previously fixed parsing of
startDateandendDatefields oncampaigns to parse through the parent account's timezone into UTC asYYYYMMDDdate strings. This remains in accordance with our best understanding of the nature of those two fields based on the Campaign API Docs.This worked for most customers but for some it resulted in an error because the request for their account resulted in an empty resultset.
Based on my understanding of the API Docs there should be no reason why a ManagedCustomer shouldn't come back from the ManagedCustomerService for a customer id that the client has access to. Nevertheless we've seen multiple occasions where none come back. Falling back to UTC seems like a reasonable default although it's almost certainly wrong.