After creating an integration with Stitch Data, I realized that occasionally newly created Engagement (Calls, Emails, etc) timestamp fields in the Engagements table will be multiplied by a factor of 1000 (i.e timestamp year is 49,909 instead of 2017), which errors out in stitch data (as the service relies on the timestamp field to only contain 13 chars) and eventually creates an out-of-sync data export.
This seems like an unusual, irregular behavior. Is this a bug? I’m willing to provide more info if need be.
All of the HubSpot APIs use millisecond timestamps, so if you’re seeing a timestamp coming from HubSpot that’s not in milliseconds it’s likely a bug. If you come across an example object that’s returning a timestamp that isn’t in milliseconds, could you send me a link to the object in your portal so that I can take a look?
All dates in HubSpot should be formatted as millisecond unix timestamps. Can you give me an example of a response where you received a timestamp that was off by a factor of 1000? Knowing which API returned the incorrect timestamp would be helpful, as would the full response body if you have it.
Alas, I absent-mindedly ran my python script to update the timestamp for the aforementioned Engagement ID. But in short, would Hubspot be able to manipulate timestamps on the backend?
After I run into the snag with the ETL, it’ll show me the logs for the problematic record in Hubspot, so I’m lead to believe that these timestamp changes are happening on the Hubspot end.
.png "HubSpot Alumni"){kind=icon}
