Hubspot rendering incorrect date for timestamp value

deals

#1

Hi,

we’re having trouble sending over the correct date value for a deals closedate

our project ID is 2686683
deal id: 58721132

we are trying to send over the date (2016, 12, 28) but our Hubspot account renders (2016, 12, 27)

This is the method we are using to convert a datetime object to a hubspot compliant datetime

    import pytz
    import datetime
    import time
    tzname = time.tzname[0]
    d = pytz.timezone(tzname).localize(datetime.datetime.combine(obj, datetime.time(0, 0)))
    return int((d + d.utcoffset()).strftime("%s")) * 1000

For an event date of (2016, 12, 28), it generates: 1482883200000

We have tried setting the projects timezone to EST and UTC to no avail. it still renders (2016, 12, 27) instead of (2016, 12, 27)

Any help would be appreciated, thank you!


#2

Hi @brian

The deal property closedate is a datetime property, not a date property. Date properties need to be set to midnight UTC for the date you want to use, but datetime properties store the time and date, and the date displayed will be the date that the set time represents, so if you want the 28th to be displayed, you’d need to use a timestamp that represents the 28th in your local timezone. You can see the full date and time in the history for the property.


#4

when I send over time value that is not corrected for UTC offset, i get:

“isValid”:false,“message”:“1480568400000 is at 5:0:0.0 UTC, not midnight!”,“error”:“INVALID_DATE”,“name”:“event_inquiry_submission_date”}],“requestId”:“a3ab39ec-6b29-4bad-8caa-e643b8af343c”

so the 5:00:00 comes from us being in EST.

the error returns: invalid date. still not sure how to proceed :frowning:


#5

upon further inspection, the helper function I was using was being shared with a field that was a date field.

Thank you for your help!


#6

@brian we have two types of properties for storing time values, date and datetime.

  • date properties need to be set to midnight so that the same date is displayed regardless of the time zone.
  • datetime properties can store any time, and get displayed based on the timezone of the person viewing the record.

That last error was happening because that property is a date property (unlike the closedate which is a datetime), so that one needs to be set to midnight.

We have some more details about those property types here:


#7

But, you can’t effectively select a time then in the Hubspot UI, say, to filter for list creation. Is this accurate?


#8

@lightcap That is correct. The lists UI will only allow you to set a date, not a specific time. The lists system does support specific times internally, but If you need to use a specific timestamp, you’d need to use the Contact Lists API to update or create the list.


#9

I too am experiencing an off by 1 date. Our server JVM is running in UTC and our database is in UTC. When we store a DATE the UTC time offset is 0.

Example:
On our side we store a DATE object (see ref: http://currentmillis.com/ ) as

Sun Apr 30 2017 00:00:00 in UTC time
long millis = 1493510400000

We send over this json
{closedate=1493510400000}
to hubspot.

On the Hubspot side we have the CRM Configuration time zone set to UTC (UTC+0)
however the close date for the deal is rendered as 04/29/2017

What should we be sending over such that we don’t have an off by 1 close date?


#10

@jsimone the closedate property is a datetime property, not just a date, so it can store any date with a time value. As mentioned above, datetime properties are displayed based on the time zone settings of your system, so you’ll see the date based on your system and not the time zone setting for the portal.


#11

thanks @dadams - I got all that and I read the whole thread. BUT …

What should we be sending over such that we don’t have an off by 1 close date?

Can you provide some sample code?

Here is what I am doing now: “closedate” is Long.valueOf(form.getCloseDate().getTime()).toString()

Date is correct when pushed up from my local machine in EST but is incorrect running on our server in UTC.

Thank-you for your help.


#12

We are seeing the same issue on our end. The saved date seems to display differently based on the timezone.

Any idea how to correct this?


#13

@dadams I hate to be a pest but we're getting new subs everyday that are effected by this issue. What is the answer to this?


#14

We experience the same problem for some month now whilst using the date field in design manager 2.0. It's really annoying. I had opened a ticket month ago, but the problem was not solved until now.

THE RIGHT SOLUTION:

Just use the to_local_time function from HubL!

{{ to_local_time(datetimeobject) | datetimeformat('%e %B %Y %H:%M') }}

DIRTY FIX (JUST FOR INFORMATION - DO NOT USE!!!):

Further investigation brought me to a first but dirty hack:

Out timezone: CET
Standard-Deviation to UTC: +1:00 Hour

{{ datetimeobject | add(+3600000) | datetimeformat('%e %B %Y %H:%M') }}

The add(+3600000) filter solved it

Solution:

Take your timezones standard deviation to UTC (e.g. CET = +1) and multiply that value with 3600000 (3600000ms = 1 hour). Finally put the result into an add filter like shown above.

Source: https://en.wikipedia.org/wiki/List_of_UTC_time_offsets#/media/File:Standard_World_Time_Zones.png


#15

Hi David,

please check if my solution solves your problem.
If so, do not hesitate to give me a like!

Best,

Arno


#18