Contacts API not accepting timestamp

[#1]

This is the response I get when I submit this timestamp. The timestamp looks fine when I test it here. What's the problem guys?

Hubspot::RequestError: Response body: {"status":"error","message":"Errors found processing batch update","correlationId":"c3497755-4296-4062-8259-70c1804a4922","failureMessages":[{"index":0,"propertyValidationResult":{"isValid":false,"message":"1526947200 is at 16:9:7.200 UTC, not midnight!","error":"INVALID_DATE","name":"first_booking_date"}}],"requestId":"8315a8306ec70b2fe1ab03ff75e57c5d"}

Thanks,
Andrew

[DRead]

I was able to update a property via the API.

curl --request PATCH \
--url 'https://api.hubapi.com/crm/v3/properties/{object}/{property_name}?hapikey={key}' \
--header 'content-type: application/json' \
--data '{ "type": "datetime", "fieldType": "date" }'

[himanshurauthan · Accepted solution]

HubSpot has two types of contact properties for storing times, date and datetime. Any properties created in the HubSpot application in Contact Settings would be date properties.

Date properties will only store the date, and must be set to midnight UTC for the date you want. For example, May 1 2015 would be 1430438400000 (01 May 2015 00:00:00 UTC). If you try to set a value that is not midnight UTC, you will receive an error.

more you can find here

[juli1]

Looking at the API definition, this is probably the worst design decision I could imagine. Not only engineers need to make sure the timestamp is right at midnight (and will potentially lead to a lot of errors from the API) but the API is not flexible enough to do the conversion itself or accept other types (e.g. datetime) in the form.

[merfin29]

I agree this makes no sense at all. I was testing and integration for hours and it just so happened all my previous values were at midnight so they went through and then suddenly I had a few which were not.

Why I asked for a format if you don't want that format? Don't ask me to choose a number between 1 and 1 that's smaller than five and bigger than four. Just say give me a number between 4-5. 

If you wanna date and you don't want any hours, then take in a date yyyyMMdd

why do extra code that serves no benefit and install a value that if corrupted would break everything else.

Also this approach is wrong. Depending on the user time zone you will sometimes be off by a day.

And then I'm guessing you doing this because you want to be able to compare 2 fields and see if they're the same date by saying A==B.

The problem is you're not guarding the field itself so somewhere in the millions of places where this field is used one day you're gonna get an error wear an unguarded value goes in. You're still using the same assumption that everything is perfectly UTC midnight. When you display this value it will look like a certain day but when you compare with another value it will no longer be equal because it will be off by seconds. In your interface you look at Jun 3 != Jun 3 and never be able to workout why it's not working.