Deal Create Date Property Value different than Date

[tjsimpson]

Hi all thank you in advance for your help!

I am experiencing a strange situation. Deals are handled via our internal systems and using the API new Deals and updated Deals are pushed to HubSpot. No one but me can modify deal records in HubSpot and even if we could they will be overwritten on the next update from our source system.

We write various fields via the API including Create Date. I have many examples where the Create Date is somehow prior to the date the deal was ever created. See below an example where this Deal was created on 03/15/2024 at 3:37 PM which is shown in the Date field but the Property Value is somehow set to a datetime prior.

 
The record in my database that is being written to this field in this particular example:
2024-03-15

EDIT: 
Here is an example of how the Deals are being updated via the API:

In this particular example the createdate is '03/15/2024'

This is causing us issues with our Deal views and I am hoping someone can help out! Thank you!

[RSchweighart]

Hi @tjsimpson,

HubSpot automatically populates the create date when the deal is created.

It seems like the discrepancy is from the create date being passed in the body request of the API call.

Are you wanting a create date separate from when the API request creates the deal in HubSpot?

If you don't want a separate create date, removing it from the body request will allow the create date to be automatically applied by HubSpot.

If you are wanting a separate create date/time, do you know the time that's being passed in the API request? Is it Alaska Time, UTC, Eastern Time, some other time zone? This may be the issue.

Best,

Ryan Schweighart

Whole Hart Impact, LLC

whimpact.co

I help businesses with HubSpot and Zapier. 

[tjsimpson]

@RSchweighart 

Thank you for your reply.

I was hoping that I can pass my own create date to the API. There are 2 cases that I was trying to solve for with this approach. First, if there is ever an issue and the pipeline fails to run and is run at a later time then the create date will be inaccurate. Second, our change data capture runs every hour so the create date will almost always be up to an hour off our source system.

At this point I would be okay with these potential pitfalls mentioned above but the fact that the property value is being set to a previous point in time is concerning. I cannot find any details on how to validate timezones. If I create a Deal manually the time is set accurately. I am going to remove the create date from the pipeline and keep an eye on the property values.

[RSchweighart]

You're welcome, @tjsimpson. Thanks for the clairification in the first paragraph. Unless you need the granularity, the hour difference shouldn't be an issue if/when you leverage the Create Date in HubSpot.

I know you're testing letting HubSpot apply the create date, but what timezone are you sending the API requests from? I'd be curious to know a little more about where/how you are generating the create date/time you want to pass to HubSpot. Also, when you say manually create a deal, are you referring to a manual test of the API call or manual creation in HubSpot from HubSpot's native create a deal form?

[tjsimpson]

@RSchweighart 

The code that POSTs to the HubSpot API are in containers hosted on US East cloud (Azure). I would imagine this means that they are US East/UTC-5. When I check the API Calls in the HubSpot developer account on the app the timelines match this. I.e. the last POST was at 9:30 AM EST today which is when it is scheduled on the hosted code.

The create date is a date type field in a SQL database. I have a view that is used as the data source to POST Deals to the HubSpot API.

Using the test record I brought up in my initial post:

The create date field in the database has a value of '2024-03-15'.

In HubSpot it shows Date of 03/15/2024 at 3:37 PM EDT and a property value of 03/14/2024 8:00 PM EDT.

The date was written by HubSpot on creation because that is the time that the integration ran. The problem is if I apply a filter on a view in HubSpot it is using the property value. Because of this I think removing the create date from the API POST code will alleviate the issue. Other than the potential issues I outlined in my last post.

I think that the format of the create date may be causing some discrepancy since it appears it may need to be a datetime as opposed to a date. I am unable to find an example of create date in the docs probably because it is not commonly used or maybe not intended for use how I am using it.

[RSchweighart · Accepted solution]

@tjsimpson, I agree letting HubSpot apply the create date/time is probably the way to go since updates are happening every hour.

Here's what I found in HubSpot's API docs regarding date/time values: https://developers.hubspot.com/docs/api/faq#:~:text=Copy-,How%20should%20I%20format%20timestamps%20f...

If you want to apply your own create date/time, I think what you'll need to do is convert your create date/time to UTC, so add 5 hours and format it like this prior to making the POST request:

2020-02-29T03:30:17.000Z

[tjsimpson]

@RSchweighart 

Thank you for these docs. This makes a lot of sense.

It actually made me realize a flow in my initial design. The create date was supposed to be date granularity according to the initial project's requirement gathering notes. This is why I was passing it as a date as opposed to datetime from the database. But it seems it was operating as datetime in HubSpot anyways so the sub-hour accuracy was never needed.

An integration just ran and the create dates are now set by HubSpot and can accurately be filtered in views. Thank you for all your help! Marking your last reply as the solution.